WTP 3.2.x Maintenance

WTP 3.2.x Maintenance Plan

Overview

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.1 will be available in our own webtools software repository, but not the Eclipse common Helios repository or EPP packages.

WTP 3.2.2 is for the first Helios simultaneous maintenance offering, delivered on the fourth Friday of September, 2010

WTP 3.2.3 is for the second Helios simultaneous maintenance offering, delivered on the fourth Friday of February, 2011.

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

Schedule

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

Project lead review and approval until July 1

7/1 Declared M-build

PMC 1 review: July 2 - July 8

7/8 Declared M-build

PMC 2 review: July 9 - July 15

7/15 Declared M-build <== final build, unless blockers found

PMC 3 review: July 16 - July 22

7/22 Declared M-build <== final build, if needed

July 23 - July 30 is "quiet week" to allow in depth testing with no changes

7/30 Official Release

3.2.2 schedule

8/3 Start R3.2.2 builds against (same) maintenance branch of map files (R3_2_maintenance, R2_3_maintenance for Dali)

Project lead review and approval until Aug 27

[Our WTP 3.2.1 release will be used to contribute to Helios SR1 RC1 +2 due on 8/11]

8/13 Declared M-build

8/20 Declared M-build

8/27 Declared M-build [contributed to Helios SR1 RC2 +2 due on 9/1]

PMC +1 review: Aug 27 - Sep 3

9/3 Declared M-build [contributed to Helios SR1 RC3 +2 due on 9/8]

PMC +2 review: Sep 3 - Sep 10

9/10 Declared M-build <== final build [contributed to Helios SR1 RC4 +2 due on 9/15]

PMC +3 review: Sep 10 - Sep 24

Sep 10 - Sep 24 is "quiet week" to allow in depth testing with no changes

Any "stop ship" builds needs not only PMC review/approval, but also Planning Council Exception, after 9/15

9/24 Official Release

3.2.3 schedule

10/29 Declared M-build

11/05 Declared M-build

11/19 Declared M-build

12/03 Declared M-build

12/17 Declared M-build

01/07 Declared M-build

01/14 Declared M-build [contributed to Helios SR2 RC1 +2 due on 01/19]

PMC +1 review from 01/14 to 01/28

01/21 Declared M-build

01/28 Declared M-build [contributed to Helios SR2 RC2 +2 due on 02/02]

PMC +2 review from 01/28 to 02/04

02/04 Declared M-build [contributed to Helios SR2 RC3 +2 due on 02/09]

PMC +3 review from 02/04 to 02/11

02/11 Final M-build [contributed to Helios SR2 RC4 +2 due on 02/16]

02/25 Official Release

3.2.4 Schedule

3/11 M build

3/18 M build

3/25 M build

4/1 M build

4/8 M build

4/15 M build (after this build, begin PMC-review rampdown (+1 begins)) Anything following this would be only for serious regressions.

4/22 M build (after this build, begin +2)

4/29 M build (after this build, begin +3)

5/06 M build final build (with one week of buffer following this week, quiet week, until 5/12 (respin would requires +3))

5/13 WTP 3.2.4 GA

3.2.5 Schedule

6/17 M build

...

Regular weekly M builds

...

9/30 M build

10/7 M build (after this build, begin PMC-review ramp-down (+1 begins))

10/14 M build (after this build, begin +2)

10/21 M build (after this build, begin +3)

10/28 M build final build (with one week of buffer following this week, quiet week, until 11/4 (re-spin would require +3))

11/4 WTP 3.2.5 GA

Scope

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).

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.

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.