Re: [RFC] 3.1 branching

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 25 Sep 2008 15:08:32 +1200 (NZST)

> 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.
>
>
>
Received on Thu Sep 25 2008 - 03:08:39 MDT

This archive was generated by hypermail 2.2.0 : Thu Sep 25 2008 - 12:00:06 MDT