5.2.6 in my scheme would just be that: 5.2.6. We could have had 5.2.6-alpha or 5.2.6-RC if we had seen the need for it but there wasn't.
In fact what I proposed would make things even easier and less beaurocratic than it is now: No new versions in Jira for unstable releases except if we wanted them, no formal votes (since it is declared a test package) and no need for all the other formalities (are NOTICE and LICENSE files in place, is the source package in order,...) required for a full Apache release. And it would allow users to see the status (alpha, beta, RC) at a glance. Uli Am Do, 23.06.2011, 19:13 schrieb Howard Lewis Ship: > I tend to like the current approach, especially as it reaches the > division between a release candidate and a final release. The way we > currently, retroactively, set the "stability" of the version, based on > exposure to users, is I think quite sensible AND the Apache Way. > > What would 5.2.6 be under your scheme? "5.2-maint-2", perhaps? > > What I'd really like to avoid is having to go through the release > cycle again (to go from, say, 5.3-rc-3 to 5.3 -- the final release). > Being able to vote up its stability and just adjust the docs, and tell > the community that the bits they have are now the final release with > no further download, is a big win in my opinion. > > On Thu, Jun 23, 2011 at 6:02 AM, Ulrich Stärk <[email protected]> wrote: >> If you feel that way my second suggestion might deserve some more >> discussion: Why don't we only >> release stable versions and provide interested early adopters and >> testers with test packages that >> carry clear identifiers like -alpha1, alpha2, RC1 and so on but have the >> same version number as the >> to-be-released stable version? We maybe even don't necessarily have to >> vote on these test packages >> as they aren't formal releases. >> >> Our process could than be something like >> >> 1. Set on the version number for the next stable release, e.g. by >> incrementing the previous version >> number. For example: next stable release will be 5.3.1. >> 2. From time to time provide interested early adopters with test >> packages after shortly discussing >> on the dev list whether it is alpha, beta or RC quality. For example >> 5.3.1-alpha2, 5.3.1-RC2 > > I vaguely remember that there's a requirement that releases > (definition subject to discussion) require a vote. > >> 3. Cut a release once we think a release candidate has reached a point >> where we can call it stable. >> E.g. 5.3.1 (without any further additions). Needs a formal vote. >> >> Uli >> >> On 23.06.2011 14:25, Thiago H. de Paula Figueiredo wrote: >>> On Thu, 23 Jun 2011 05:15:47 -0300, Ulrich Stärk <[email protected]> >>> wrote: >>> >>>> I guess we can continue as before. The only thing I'd like to see >>>> changed is the addition of the >>>> status of the release to the version number. I.e. alpha, beta, ... >>> >>> Agreed. I'd just leave the stable releases without suffixes and append >>> alpha, beta, rc or >>> something like that to emphasize that a release isn't stable. >>> >>> To me, the last vote was confusing: it says "5.3.0" without any >>> indication that it isn't a stable >>> release. Anyone that doesn't follow the dev list would probably think >>> it's a stable release, I guess. >>> >> >> --------------------------------------------------------------------- >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
