Difference between revisions of "WTP 3.5.x Maintenance"

From Eclipsepedia

Jump to: navigation, search
(Overview)
 
(2 intermediate revisions by one user not shown)
Line 3: Line 3:
 
== Overview ==  
 
== Overview ==  
  
WTP 3.5.1 is for the first Kepler simultaneous maintenance offering, delivered on the fourth Friday of September, 2013(9-27)
+
:WTP 3.5.1 is for the first Kepler simultaneous maintenance offering, delivered on the fourth Friday of September, 2013(9-27)
WTP 3.5.2 is for the second Kepler simultaneous maintenance offering, delivered on the fourth Friday of February, 2014(2/28)
+
:WTP 3.5.2 is for the second Kepler simultaneous maintenance offering, delivered on the fourth Friday of February, 2014(2/28)
  
 
For severe issues that require an immediate patch, see [[WTP_Patches | WTP Patches]].
 
For severe issues that require an immediate patch, see [[WTP_Patches | WTP Patches]].
Line 30: Line 30:
 
::: September 13 - September 27 is "quiet" to allow in depth testing with no changes
 
::: September 13 - September 27 is "quiet" to allow in depth testing with no changes
 
:: 9/27 Official Release
 
:: 9/27 Official Release
 +
 +
===3.5.2 schedule===
 +
 +
 +
:: 10/1 M (continuous) builds started
 +
::: Project lead review and approval until January 16
 +
:: 1/17  Declared M-build(RC1)
 +
::: PMC +1 review: January 17 - January 30
 +
:: 1/31  Declared M-build (RC2)
 +
::: PMC +2 review: January 31 - February 6
 +
:: 2/7 Declared M-build (RC3) <== final build, unless blockers found
 +
::: PMC +3 review: February 6 - 28(GA)
 +
:: 2/14 Declared M-build (RC4) <== final build, if needed
 +
::: February 14 - February 28 is "quiet" to allow in depth testing with no changes
 +
:: 2/28 Official Release
  
  

Latest revision as of 13:19, 3 October 2013

Contents

[edit] WTP 3.5.x Maintenance Plan

[edit] Overview

WTP 3.5.1 is for the first Kepler simultaneous maintenance offering, delivered on the fourth Friday of September, 2013(9-27)
WTP 3.5.2 is for the second Kepler simultaneous maintenance offering, delivered on the fourth Friday of February, 2014(2/28)

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


For overall Kepler Maintenance dates, see Kepler#SR1 and Kepler#SR2.

[edit] Schedule

Typically, M-builds are declared weekly.


[edit] 3.5.1 schedule

7/25 M (continuous) builds started
Project lead review and approval until August 15
8/15 Declared M-build(RC1)
PMC +1 review: August 16 - August 29
8/29 Declared M-build (RC2)
PMC +2 review: August 30 - September 5
9/5 Declared M-build (RC3) <== final build, unless blockers found
PMC +3 review: September 6 - 27(GA)
9/12 Declared M-build (RC4) <== final build, if needed
September 13 - September 27 is "quiet" to allow in depth testing with no changes
9/27 Official Release

[edit] 3.5.2 schedule

10/1 M (continuous) builds started
Project lead review and approval until January 16
1/17 Declared M-build(RC1)
PMC +1 review: January 17 - January 30
1/31 Declared M-build (RC2)
PMC +2 review: January 31 - February 6
2/7 Declared M-build (RC3) <== final build, unless blockers found
PMC +3 review: February 6 - 28(GA)
2/14 Declared M-build (RC4) <== final build, if needed
February 14 - February 28 is "quiet" to allow in depth testing with no changes
2/28 Official Release


[edit] Scope

All WTP 3.5.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).

Exceptions to the above are sometimes required, but they 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.

[edit] 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.