On Fri, Jun 24, 2011 at 2:56 PM, Thiago H. de Paula Figueiredo <[email protected]> wrote: > On Fri, 24 Jun 2011 18:43:17 -0300, Massimo Lusetti <[email protected]> > wrote: > >> OpenBSD is an open source operating system project and is by far a lot >> more complicated then a web framework. >> It has a streamlined release process which results in a series of >> successful releases, plus the OpenBSD's snapshots are by far a lot >> more stable then a lot of other operating system "stable releases", I >> see Tapestry release and snapshots story very similar (especially in >> term of stability) > > So I think we don't need to call 5.3.0 an alpha release. :) As you > suggested, let's consider snapshots as our alpha releases.
I think we are colliding on terminology here. Motivated types can download the source and build it. However, users using Maven, Gradle or Ivy will benefit greatly from having a pre-compiled release in a repository, preferably Maven Central. Further, it would be good if that version number did not include the suffix "-SNAPSHOT". That brings us full-circle to where we started. It seems like the best way to resolve this is to modify what we've been doing, and add a new step. Instead of a simple suffix, we can incorporate a stability designation. Thus "5.3-alpha-1" instead of "5.3.0". Once a release is voted up in stability (that is, voted from "alpha" to "beta", "beta" to "rc" or "rc" to "final"), the FOLLOWING release gets the new stability, with the assumption that no changes between the vote and the release cause instability. In other words, when we vote "5.3-beta-2" as a release candidate, then the NEXT release will be "5.3-rc-1" ... and its bits should be as close as possible to 5.3-beta-2 ... and ideally, the only difference should be the version number. Final releases will have no suffix, i.e, we might vote "5.3-rc-2" as final, and then release "5.3". TBD: Process and naming conventions for bug fix releases. Should the first bug fix release on top of 5.3 be called "5.3.1"? "5.3-fix-1"? Do we release it then vote on stability? I'm leaning towards creating and voting on a "5.3.1-rc-1" containing the fix, then voting that as stable to release "5.3.1". Note that does represent a large change, and I think a large improvement, to how the third digit in the version number is interpreted. We may also want to reconsider how bugs are assigned to JIRA versions. I would think that, perhaps, we should have a JIRA version for each final release; so just a 5.3 and a 5.4. We would also create a JIRA version for each bugfix release, such as 5.3.1. The same approach should apply to our @since tags. So my proposal: Tapestry release version numbers consist of three numbers and an optional suffix. The first number is "5", the product number (thus Tapestry 4 was a different product). Let this never be "6"! The second number is the major release. Currently this would be "3". The third number is the bugfix release number. This is currently not present, as Tapestry 5.3 has not had a final release yet. The suffix indicates stability and includes a sequence number within the stability. The stability term is "alpha", "beta" or "rc" in ascending stability. The suffix concludes with a dash and a sequence number, such as "alpha-2", or "beta-3". The suffix, when present, is separated from the release number by a dash. alpha releases are known to be incomplete and in-flux beta releases represent stability of features, with an emphasis on fixing bugs in new and existing code rc (release candidate) releases represent the most stable code, with only the most serious bugs being fixed Thus a complete version number might be "5.3-alpha-2". final releases have no suffix, thus "5.3" will be the final version number for the Tapestry 5.3 major release After a release has been made available for a reasonable period (up to several weeks for a release candidate), a stability vote may be run. A successful stability vote will spur the creation of a new release with the next level of stability. Example: a successful stability vote on "5.3-beta-2" will allow the next release to be "5.3-rc-1". An unsuccesful stability vote should result in a work towards a new release at the same stability. Thus, if the stability vote for "5.3-beta-2" fails, there should be follow-on work to create a "5.3-beta-3" release, then a vote on that. Bug fix releases follow an abbreviated stability schedule, starting automatically at "rc" (release candidate) status. How does that sound? It also means that our next version number will be "5.3-alpha-2" ... and perhaps we should consolidate our JIRA version numbers. Let's have more discussion, then run a lazy consensus vote, and get this documented in the wiki. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and > instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > > --------------------------------------------------------------------- > 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]
