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 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]
