> On Wed, 2008-09-24 at 20:56 +0200, Henrik Nordstrom wrote: >> On tor, 2008-09-25 at 03:32 +1200, Amos Jeffries wrote: >> >> > I only have one question: how well does that release numbering model >> > match the other OSS projects using the same numbering system? We don't >> > want to set our own method and meaning when there is already a common >> > way to get confused with. >> >> Numeric numbering with 0 as "beta" is used by many packaging schemes, >> and would not confuse anyone. >> >> I am positive on getting rid of the labels and use the scheme proposed >> by Kinkie. > > Cool. So, if there are no objections, we have: > > 0) Trunk is usually open for new stuff. Make daily snapshots. > 1) Branch X.Y when major features are committed. Snapshots. > 2a) Release X.Y.0.0 when all major bugs are fixed. > 2b) Release X.Y.0.w as code gets better, w >= 1. > 3a) Release X.Y.1 when the last X.Y.0.w was "stable". Mark branch as > stable. > 3b) Release X.Y.z as bugs get fixed, z > 1.
Well, They way I'm thinking of the numbers your sequence is 1-off. We are not stopping the daily snapshots, I think. So your 4-th place digit is the same as the snapshot date. We have NO new features added after X.Y.0, NO non-bug changes at all. Stability seems to be taking the same length of time as a new Y release. Which means we end up with 3.1.1, 3.2.1, 3.3.1 with possibly many smaller 4-place releases for each day or bugfix patch. 3-levels should be sufficient. It's also not a major change from current practice, only dropping the name 'STABLE' from packages. We don't really need the RC flag-days in my scheme either. I just thought it would be slightly more descriptive for people to understand the .0 code in those bundles is still not proven trustworthy for production. Also leaves the option if a major bug fix went in (rare) we could -rc a few test bundles before declaring it fixed). > > If needed, flag any snapshot or numbered version as Release Candidate. > These flags do not affect the version number. > >> To answer Alex regarding the RC (Release Candidate) this is not a >> release tag in itself. It's more of a temporary flag. It has also used >> between STABLE releases if there has been large or packaging changes, >> and those releases is not announced outside squid-dev or visible on the >> web site. > > Sounds good. > > Thank you, > > Alex. > > >