Difference between revisions of "WTP 3.1.x Maintenance"

From Eclipsepedia

Jump to: navigation, search
(3.1 maintenance)
 
(WTP 3.1.x Maintenance)
 
Line 6: Line 6:
  
 
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]].
 +
 +
For overall Galileo Maintenance dates, see [[Galileo#SR1]] and [[Galileo#SR2]].
  
 
== Schedule Details ==
 
== Schedule Details ==

Latest revision as of 12:39, 6 August 2009

Contents

[edit] WTP 3.1.x Maintenance

WTP 3.1.1 is the first WTP Galileo maintenance offering, delivered in September.

WTP 3.1.2 is the second WTP Galileo maintenance offering, delivered in February, 2010.

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

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

[edit] Schedule Details

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


[edit] 3.1.1 schedule

See also the Galileo ramp down dates


7/17 M Build
7/31 M Build
8/14 M Build
8/28 M Build (PMC Review starts following this build)
9/04 M Build
9/11 M Build Final Build
9/25 Galileo SR1


[edit] 3.1.2 schedule

...
Galileo SR2 2/26/10 (will be WTP 3.1.2) (last Friday of February)

[edit] Scope

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

All exceptions to the above require PMC approval.

In general, we will avoid changing the interface or behavior 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. 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 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 release candidate, all bugs must also be approved by the normal PMC Approval Process.