Richard Lewis-Shell: +1 (binding) On 30 June 2011 05:03, Howard Lewis Ship <[email protected]> wrote:
> 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] > >
