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!).

They are, very similar. I just don't see any need for 4-numbers in Kinkies
Scheme.

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

Okay, using actual numbers and timelines of 3.1/3.2 to make it clearer
than the abstract. Dates are mostly fictional but based on reasonable
guesses.

trunk (3.1.0)
 -> sept 30: branch with 10 new features
    release 3.1.0
    (makes trunk now 3.2.0)
 -> oct 30: everything found 'stable'
    release 3.1.1
 -> nov 30: 10 new major+ bugs fixed :-(
    release 3.1.2
    (move 3.1.1 down to obsolete list)
 -> dec 30: 2 new major+ bugs found
    release 3.1.3
 -> jan 1 : branch with 9 new features
    release 3.2.0
    (makes trunk now 3.3.0)
 -> feb 1: everything found 'stable'
    release 3.2.1
    release 3.1.4 final bug fixes.
 -> ...

trunk continues its merry way getting new features the whole time as 3.*.0
without any flag points.

grok?

Nothing implies a guaranteed STABLE. Merely the highest number (ie 3.1.4)
is most bug-free for all fixable problems of 3.1 branch, snapshot for
testing ports work between releases.

We may reach 3.1.6 if things go badly, or if new features get developed
really slowly. But I don't think we will get enough checkpoints in the
devel cycle to warrant two layers of .0.1 -> .6.2

People seem happy with the release approach and timelines, just not the
current bad naming scheme which implies releases are guaranteed STABLE
when in fact only a bug fix improvement.

Amos
Received on Thu Sep 25 2008 - 04:20:36 MDT