Re: [RFC] 3.1 branching

On ons, 2008-09-24 at 13:56 -0600, Alex Rousskov wrote:
> 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.

Sounds good to me, but see below for a minor adjustment and reasoning.

> If needed, flag any snapshot or numbered version as Release Candidate.
> These flags do not affect the version number.

Correct.

With this scheme labels is outside the revision numbers and only a
"human" concept in the text describing the releases (i.e. website and
announces). Also allows us to revoke the "stable" label from any version
known to have issues by simply updating the description,

Only comment is that 1 is a little fuzzier than described above

1 should take place when the tree is in a state the release manager and
others involved in the process considers a good startingpoint for
getting to 3. May still be major features missing, or there may even be
too many features at that time.

During 2 there is a significant flow of changes from trunk to the
branch, and also stuff getting revoked from the branch and deferred to
trunk waiting for the next release.

But if there is a major feature pending for trunk which is not targeted
for the branch then it's better to branch before that gets merged, even
if waiting on other major items which may get into trunk after. But both
ways are doable.

It's also important to keep good quality of the changes going into
trunk. The intention is that from a quality perspective trunk should
always be in shape for 1, with 2 being a fairly short process (a month
or so).

The .0.w releases should mainly take place at the near end of 2. Before
that the nightly snapshots serves the purpose well I think.

To get the snapshot numbering right and some other similar tasks
the .0.0 release should be the branch point, and will most often be
skipped as a release as such. For cosmetic reasons using just .0 may be
better.

So we have

1. Branch when trunk is considered a suitable startingpoint for getting
to stable, and tag a x.y.0 release at the branchpoint (or at least set
this version in configure.in).

2a. Release X.Y.0.1 when ready for testing
2b. Release X.Y.0.w as code gets better, w > 1

Regards
Henrik