I fully understand Howard's reasoning but to me it comes down to whether you believe there is such a thing as a final release or not. Under the current, numbers-only release scheme, the micro version can be read as an indication of stability. Instinctively, it makes sense that micro release .0 is less stable than .9 for example. I'm worried that proposed, new version scheme will not have the desired effect, but alpha, beta,rc release will only make us release less frequently and each pre-release may not gain enough audience to meaningfully contribute to the stability of the release - in other words, what often happens, is that people will wait for whatever release is deemed "final" before coming to kick the tires. It could be argued that more frequent releases create more buzz (Jenkins, Jitsi as examples) since the *perceived* development velocity seems higher whereas less frequent stable releases are more desirable for existing users.
It could increase users confidence in upgrading between micro versions if we simply guaranteed that micro versions are backwards compatible. I do understand Howard's concern with working on new code paths that are still in flux, since it's difficult to guarantee that interfaces for the code you are prototyping are not going change. If that leads to more frequent minor versions, so be it, it's not like we are going to run out of minor versions either. For a web framework, rather than an end-user product, it seems to me it's less compelling to produce a final release that has gone through several rounds of limited field testing. These are not necessarily the opposite proposals - especially if we are not voting on pre-releases/release previews, the actual numbered releases can keep the current numbering scheme as is, and previews is just an added step to evaluate a specific version in development (in other words, a mechanism to freeze a development version to share the same snapshot between all interested parties). A release in Apache terms is a source package on dist, any binaries are provided as a convenience only. Kalle On Tue, Jun 28, 2011 at 9:22 AM, 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 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. > > -- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
