WTP Development Status Meeting

Remember, any committer can add an agenda item. Typically, short announcements or news items go in the "Announcements" section at the beginning. Longer items or issues requiring discussion should go in the "Other business" section at end.

3.4.0 Schedule

Bug Review

Other business

Smoketest discussion

We had a discussion several weeks ago regarding expectations for projects smoke testing each weekly declared build, and in the case of WTP 3.2.5 allowed teams to skip if they didn't contribute to the release. We understand the heavy workloads of many teams, and want to be flexible, while maintaining stability and limiting risk for adoption on our declared drivers.

We (PMC) are proposing that the 3.3.2 maintenance builds will only require smoke tests if teams have contributed that week, or dependencies have changed. If not, project leads have the discretion to skip. We will have this policy until around mid December, when we will start mandatory smoke testing this release. This should give some flexibility to the project leads. The 3.4 release will remain mandatory every week.

Review additional API "Guidelines"

Thinking of making a change that effects a public or private api? Our goal is to maintain a stable, low risk, and safe environment for maintenance releases, while also allowing a flexible but well documented policy for API change in any current development release. These guidelines should help determine the best course of change to a component.

Maintenance release:

Breaking changes to public API is never allowed. Non-breaking changes to public API is discouraged but exceptions must be reviewed by the PMC. Changes to existing internal api is discouraged, and an new alternate api is always preferred. If making a change to an existing Interface class, always consider adding an extension interface to prevent breaking adopter implementers. API also includes extensions point declarations and implementations if backing api classes (Example: Facet/Runtime extensions and classes). Adding features in a maintenance release is discouraged, exceptions should be brought to PMC, and a separate feature release should be considered to minimize adopter risk.

Current or Maintenance release:

In any release (maintenance or current) any api change that causes backward compatibility breakage must be reviewed by the PMC. Any non-breaking change to an existing api in a current release is allowed but should be well documented, and shared with the community.

Indigo release retrospective

References

↑Our plan dates are on 'Friday' of the week. But, we produce and test the build on Thursday of the week, and ideally declare on Thursday. The dates in the Google Web Tools group calendar are for 'Thursdays' since that's a calendar for committers. We give ourselves the buffer to Friday, as our "public" date, that others can pick up our build, just in case a regression is found on Thursday and we have to respin and retest. [Technically, some might say, we still have till the following Tuesday or Wednesday for some "Simultaneous Release" due dates ... but it's hard to do much in that window, without disrupting everyone ... so we'll not use that buffer, except for the worst emergencies.]