On Tue, Jun 28, 2011 at 10:57 AM, Ulrich Stärk <[email protected]> wrote: > > > 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. >
That would be very nice ... so we vote on stability (lazy) and on the final release (full), but any dev can create a preview at any time. That will streamline a lot of things! > Otherwise: +1 > > Uli > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- 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]
