On 28.06.2011 18:22, Howard Lewis Ship 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 final releases are available to a wide audience before > being voted as final. > > Tapestry version numbers for stable releases will henseforth 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" releases are not stable; the represent functionality in flux; > classes and methods may be renamed or otherwise refactored between > releases. > > "beta" releases occur once main functionality is complete; they exist > to fix bug in old and new functionality, and fill and gaps in > functionality. > > "rc" releases 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 extact 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 should be advanced to > the next index number within the same stability series (example: > "5.3-alpha-2" to "5.3-alpha-3"). > > Following a lazy-consensus vote, the 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 successful preview release vote. This is > to vote the code base up to the next level of stability (to "beta", > then "rc", then "final"). This is also a lazy consensus vote. > > Once a release is final, a final release may be built and uploaded to > the Apache Nexus. A final release also includes additional non-Maven > artifacts containing the project's source code, and additional > artifacts containing JavaDoc or other reports. > > The final 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 releases > 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 "final") > is followed by a release vote. > > > PROS: > > At-a-glance identification of version stability. > Alignment of Tapestry product releases ("5.3") with Tapestry version > numbers ("5.3", then "5.3.1"). > Streamlined procedures for generating and distributing a preview release. > Simplification of issue tracking in JIRA. > Most votes can be lazy-consensus. > > CONS: > > People desiring early access must search the correct Nexus repository; > this will limit the exposure of preview releases. > More voting, as stability votes are separate from preview and final > release votes.
As I said before, my understanding is that we can omit voting on preview packages since they are no releases in the sense of the ASF. A lazy consensus vote is nice though as it keeps the community involved. Otherwise: +1 Uli --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
