Jump to: navigation, search

WTP Release 2.0.x Maintenance Plan and Policies

Revision as of 19:34, 30 July 2007 by Jgarms.bea.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This document is to capture the important information for WTP 2.0.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 as the 1.5.x maintenance change policy (See [1]).

  • General expectation: 2.0 adopters should be able to take 2.0.x without problems
    • Binary compatibility is required among all point releases and 2.0
    • Source compatibility is required among all point releases and 2.0
    • Full project interoperability among these releases (e.g., a project created in 2.0.x must be usable in 2.0 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.