Skip to main content
Jump to: navigation, search

Difference between revisions of "WTP 3.2.x Maintenance"

(3.2.2 schedule)
(3.2.2 schedule)
Line 34: Line 34:
===3.2.2 schedule===
===3.2.2 schedule===
:: ...  
:: ...
:: 9/24 Official Release
<!-- ::Galileo SR2 2/26/10 (will be WTP 3.1.2) (last Friday of February)  
<!-- ::Galileo SR2 2/26/10 (will be WTP 3.1.2) (last Friday of February)  

Revision as of 09:54, 11 June 2010

WTP 3.2.x Maintenance Plan

WTP 3.2.1 is a WTP-only maintenance release, planned for end of July. It will be built on exactly the same pre-reqs from the June Helios release.

WTP 3.2.2 is the first simultaneous maintenance offering, delivered 4th Friday of September, 2010

WTP 3.2.3 is the second WTP Galileo maintenance offering, delivered fourth Friday of February, 2011.

For severe issues that require an immediate patch, see WTP Patches.

Schedule Details

Typically, M-builds are declared bi-weekly, or weekly nearer the release date.

3.2.1 schedule

6/16 Map files branched, M (continuous) builds started
7/8 Declared M-build
7/15 Declared M-build
7/22 Declared M-build
7/30 Official Release

3.2.2 schedule

9/24 Official Release

3.2.3 schedule

2/25 Official Release


All WTP 3.2.x releases are service releases for critical defects, regressions, and adopter issues only. Specifically, there should be:

No UI changes (that would effect documentation, tutorials, etc.)
No NL changes (that would invalidate translations)
No API changes, or changes affecting known adopter usage.
No new function or features (especially those that would require an increment in minor version field).

Any exceptions to the above require WTP PMC approval.

In general, we will avoid changing the interface or behavior of any public method even if non-API.

All bundle versions must be updated (with an increment in the service level field) when the first change is made to for a service release. Similar for any feature (directly or indirectly) that includes the bundle. If a bundle (or feature) does not change, it's version should not change.

Bug Approval

All bugs must be approved by the project lead or their delegate using the bugzilla review flag. Project leads should send a note to wtp-releng to notify everyone of their choice or change in delegate(s).

After the first maintenance release candidate, all bugs must also be approved by the normal PMC Approval Process.

Back to the top