Tapestry versioning structure as currently implemented in problematic for several reasons: 1. We vote and release non-final artifacts, which goes against the established model set by the board. 2. We have a proliferation of version numbers, which complicates the creation of builds, as well as tracking in JIRA. 3. Strictly numeric version numbers require a separate lookup in documentation to establish stability (alpha, beta, release candidate, final).
The latter has been seen recently with people thinking that version 5.3.0 is a final build, rather than a very early alpha build. This proposal would simplify the version numbering scheme and link it properly to the release numbering scheme, while preserving efforts to ensure that releases are available to a wide audience before being voted as stable and distributed. Tapestry version numbers for stable releases will henceforth match Tapestry release numbers. A release number consists of a product number (5) and a index number (for example, 3) separated by a dot. At the time of this writing, the stable release number is "5.2" and the development release number is "5.3". A bug fix release replaces a stable release, adding an index number to the release number. Thus the first bug fix release of Tapestry 5.3 will be Tapestry 5.3.1, followed by 5.3.2, etc. (as necessary). Only final, stable releases will be made widely available (via the Apache downloads page, or via the central Maven repository). Intermediate artifacts represent previews of the eventual stable release. The version number for such a preview is of the form "<release-number>-<stability>-<index>", where the release number is as described above, the stability is one of "alpha", "beta" or "rc", and the index number indicates the order within the stability. The index number starts at 1. "alpha" versions are not stable; the represent functionality in flux; classes and methods may be renamed or otherwise refactored between releases. "beta" versions occur once main functionality is complete; they exist to fix bugs in both old and new functionality, and fill any gaps in functionality. "rc" versions are "release candidates"; the functionality should be solid; the point of a release candidate is to get wide exposure to the new codebase to ensure that the final release is free of bugs. A preview release may be created at any time. A tag is created in Subversion to label the exact source from which the preview release is generated. The preview release is built and uploaded to the Apache Nexus. Once uploaded, the master version number (in trunk) should be advanced to the next index number within the same stability series (example: "5.3-alpha-2" to "5.3-alpha-3"). The Apache Nexus URL for the preview release may be distributed on the Tapestry user mailing list. However, preview releases are deleted, not released. This is important ... preview releases are never released to the Maven Central repository, only final releases are distributed via Maven Central. A stability vote may follow a preview release. This is to vote the code base up to the next level of stability (to "beta", then "rc", then "stable"). This a lazy consensus vote. Once a version has been voted "stable", a release may be built and uploaded to the Apache Nexus. A stable release also includes additional non-Maven artifacts containing the project's source code, and additional artifacts containing JavaDoc or other reports. The other artifacts are distributed via the Apache Mirrors. The vote for a release is a binding vote, requiring at least 3 +1 votes and no vetoes, as outlined in http://www.apache.org/foundation/voting.html Following a successful release vote, the final release artifacts in the Apache Nexus repository may be released to the Maven Central repository, and the additional artifacts moved into place for download from the Apache distribution mirrors. This is also the point at which the Tapestry wiki is updated to announce the new release (and provide proper links to it), as well as announcements on the Tapestry user mailing list and elsewhere. Bug fix releases are follow-ons to stable releases. Bug fix versions automatically start at stability "rc", reflecting the fact that only localized bug fixes are expected to be included in such a release. Once all desired bug fixes are in place, a stability vote (to "stable") is followed by a release vote. This change affects Tapestry 5.3 and up. As part of this change, @since and @deprecated tags in Java source will be modified to indicate the release number ("5.3") not the version number ("5.3.0"). In addition, the existing 5.3.x JIRA versions will be collapsed down to a single 5.3 version, which is to say that JIRA versions will now match Tapestry release numbers. Vote to last three days, and require three binding +1s and no binding vetoes. Howard M. Lewis Ship: +1 (binding) -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
