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]
