WTP Release 1.5.x Maintenance Plan and Policies

This document is to capture the important information for WTP 1.5.x maintenance release that will be of interest to adopters and committers.

Policy

The general PMC policy as agreed to and published on wtp-dev on 6/13/2006 (See 1.5.x change policy).

• General expectation: 1.5 adopters should be able to take 1.5.x without problems
  • Binary compatibility is required among all point releases and 1.5
  • Source compatibility is required among all point releases and 1.5
  • Full project interoperability among these releases (e.g., a project created in 1.5.x must be usable in 1.5 without changes)
• Without prior PMC approval, no new, changed, or deleted
  • Extension points
  • APIs
  • Features (including major UI changes)
• Changes to non-APIs must be announced on the wtp-dev mailing list. You are also required to run the adopter usage scanner to ensure WTP adopters are not affected by these changes. See the non-API change policy and how to run the adopter usage scanner.
• Bug fixes and performance enhancements are generally ok and do not require PMC approval until rampdown

UI and National Language Impacts

In order to avoid large differences between documentation (which may have screen shots, etc.) and large differnces with potentially translated versions of WTP, UI and PII changes should be kept to a minimum. Specifically, Only fixed where the doc or non-NL bug is less bad than the original bug. When required, we will track with a new bug, marked minor, that simply says something like "untranslated string" with details (which string, which plugin) listed in the body of the bug. That way we'll know if we are getting too many and should re-consider plans.

End Game Bug Triage

Especially during the final month/weeks of a release, when we are mostly fixing serious regressions and blocking defects, it is important to let the originator know how to "get the fix" to verify, or unblock their testing. In some cases, it might be easiest/best to attach a "development built" jar to the bugzilla (just make sure the qualifier in the plugin version is appropriate ... usually something like v{date-time}_devfix would work).

But, at a minimum, be sure to leave a note in the bug which "continuous build" you expect the fix to be in, and which plugin or plugins would contain the fixes, if possible. A URL to that build is ideal, but if you have to, you can "guess" and say something like "In continuous builds greater than Mxxxx", where xxxx is current date and time plus about 4 hours from the time you release it. And, then, ideally, you can verify which build contained the fix and update the bugzilla entry with more precision.

Major Dates

8/15 Deadline for "Hot bugs" to be proposed from adopters for inclusion in 1.5.1. Subsequent requests will apply to WTP 1.5.2 or 1.5.3.

8/30: RC3 (final?) for platform 3.2.1 [See the platform’s endgame plan for more details]

9/01: Component lead triage begins. All bugs reviewed and targeted accordingly; most P3 and low sev bugs not yet addressed that are nontrivial should be pushed out of the 1.5.1 release.

9/08: WTP 1.5.1 code complete. Start of PMC-level triage.

9/15: Code freeze for WTP 1.5.1 and start of downstream projects’ (TPTP, e.g.) final readiness and verification cycle. (Any requested changes or P1 bugs discovered required PMC approval to fix.)

9/15: Date by which all Callisto projects are maintenance build ready and update site loading/testing can commence.

9/27: Final posting of Callisto bits and mirror synchronization; update site locked during this time.

9/29: GA for first Callisto maintenance pack (including base 3.2.1 and WTP 1.5.1). Callisto update site, WTP update site, and WTP download page all available.(including all-in-one bundles for WTP 1.5.1).

10/31 Release of 1.5.2.

2/16/2007 1.5.3 (as part of the Callisto Winter Maintenance Release