Re: [RFC] 3.1 branching

On Thu, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
> > 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
> >
>
> Don't forget the next step after (w>1 && w<12) is:
> Branch X.Z.0 !!!!
>
> So why do we really need an extra .0 sitting on the end wasting space?
>
> I have no intentions of maintaining anything other than:
> trunk + latest X.Z.n + most stable X.Y (if X.Z.n < X.Z.1)
>
> The back-port workload becomes just too much for the few of us doing it.
> Things won't get tested well, and stability goes backwards.
>
> Lets just make STABLE release the highest of X.Y.W, .0 of that sequence
> the pre-release beta code. And flag anything we *really* need sub-releases
> of with a temporary text or even just the snapshot datestamp. Preferrably
> leaving those type of changes for a later X.Z release with testing time in
> trunk.
>
> Keep in mind the whole W-level release cycle is going to be in the order
> of months, with people who need long-term stability staying with
> high-numbered older versions.

Amos,

    I am sorry, but I honestly do not understand this and the previous
"your sequence is 1-off" email. Perhaps the dancing Xs, Ys, and Zs with
some implied meaning confuse me. It feels like there is some basic
misunderstanding, especially since yours and Kinkie's earlier
suggestions were very similar (or so I thought!).

Could you please restate your proposal in a concise step-by-step form,
as opposed to explaining why the above plan would not work? This may put
us back on the same page again.

Thank you,

Alex.
Received on Thu Sep 25 2008 - 03:43:12 MDT