Difference between revisions of "WTP 3.0.x Maintenance Schedule"
(→WTP 3.0.x Maintenance Schedule)
m (WTP 3.0.x Maintenace Schedule moved to WTP 3.0.x Maintenance Schedule: correct spelling in title)
Revision as of 22:06, 23 July 2008
WTP 3.0.x Maintenance Schedule
WTP 3.0.1 is the first WTP Ganymede maintenance offering, delivered in mid August.
WTP 3.0.2 is the coordinated Eclipse Ganymede SR1 maintenance offering. The WTP 3.0.2 deliverable will line up with all other Ganymede maintenance deliverables.
WTP 3.0.3 is the coordinated Eclipse Ganymede SR2 maintenance offering. The WTP 3.0.3 deliverable will line up with all other Ganymede maintenance deliverables.
For severe issues that require an immediate patch, see WTP Patches.
M-builds are declared weekly. Only teams with significant change in a given week (either released, affected, or accumulated) need to perform a full smoke test, and other teams can decide on the appropriate level of testing.
- July 11 - M build
- July 18 - M build
- July 25 - RC1
- All changes after July 25 require PMC approval (1 vote)
- Aug 1 - RC2
- All changes after Aug 1 require PMC approval (2 votes)
- Aug 8 - RC3 & final build
- Aug 15 - 3.0.1 GA
- Aug 22 - M build
- Aug 29 - M build
- Sept 5 - RC1
- All changes after Sept 5 require PMC approval (1 vote)
- Sept 12 - RC2
- All changes after Sept 12 require PMC approval (2 votes)
- Sept 19 - RC3 & final build
- Sept 25 - 3.0.2 GA
- Jan 9 - M build
- Jan 23 - M build
- Feb 6 - RC1
- All changes after Feb 6 require PMC approval (1 vote)
- Feb 13 - RC2
- All changes after Feb 13 require PMC approval (2 votes)
- Feb 20 - RC3 & final build
- Feb 25 - 3.0.3 GA
All WTP 3.0.x releases are service releases for critical defects, regressions, and adopter issues only. Specifically, there should be:
- No UI changes
- No NL (translation) changes
- No API changes, or changes affecting adopter usage scans
All exceptions require PMC approval.
In general, we will avoid changing the interface or behaviour of any public method as per the WTP API Policy.
All bundle versions must be updated (an increment in the service level) when the first change is made to it in a service release.
All bugs must be approved by the project lead or 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).
Starting after RC1, all bugs must also be approved by the normal PMC Approval Process.