Re: [RFC] 3.1 branching

On Thu, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
> Henrik Nordstrom wrote:
> > On tor, 2008-09-25 at 15:15 +1200, Amos Jeffries wrote:
> >
> >> 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 !!!!
> >
> > Ofcourse. trunk continues it's live and 1 restarts when suitable.
> >
> > The .0 releases is not a requirement, but may be useful depending on how
> > the release matures after the branch, which heavily depends on the state
> > of trunk at time of branching.
> >
> > But as soon as you branch the version needs to be labelled X.Y.0,
> > with .1 being the "STABLE" release. But there does not NEED to be
> > any .0.x release made at all if you as release maintainer do not want
> > to,
>
> So I should simply say 'X is how we are doing it'? I think not.
> Kinkie has somehow convinced Alex of a different way of numbering then
> simply omitting the word 'STABLE', I'm pondering it but need a good
> reason to agree.

I was just going for consensus. Personally, I am fine both with Kinkie+
(0 has a special meaning then come the stable releases) and with mine
(just keep releasing until stable) proposals.

I do not want the meaningful words like "RC" or "STABLE" to be in the
version string. And I want a way to release many times with a specific
version (not an automated snapshot) before the branch is marked as
stable.

> >
> >> 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)
> >
> > Nobody has said anything else.
>
> ? the alternative to this I'm arguing against has another layer of
> formal .N releases.

I do not think the number of releases will go up or down significantly.
>From "I do not intend to maintain more" point of view, all proposals are
the same.

> >> 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.
> >
> > Well, as soon as you have branched there will be backporting, and
> > occationally forwardporting. Mainly bugfixes, and occationally a feature
> > deemed important enough but which did not make it in time to the branch
> > point but which made it in good time before the .1 "STABLE" release.
> >
> >> Lets just make STABLE release the highest of X.Y.W, .0 of that sequence
> >> the pre-release beta code.
> >
> > That's exactly what we are saying.
>
> By my reading, Alex and Kinkie are going on about a whole lot of *.0.N
> releases required if we don't consider any particular code STABLE.
> Like they are confusing trunk stabilization with branch stabilization.

Not "any particular code". Just the freshly branched code. We can
minimize the number of those 4-digit releases if the code stays longer
in trunk, but I think you wanted to branch sooner rather than later.

> >> 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.
> >
> > We have not said anything about any sub-releases after the .1 "STABLE"
> > release, except for the possibility of a "Release Candidate" indication
> > in the web site and/or informal announcement.
>
> Alex has indicated his understanding of NO sub-numbering after X.Y.1,
> which equates to no -RC.

You are both right. What Henrik is talking about is announcing a given
version as "release candidate". What you are talking about is not using
"RC" in the version string. There is no contradiction here. To reduce
confusion, "release candidate" should be renamed to something like
"stable candidate". It is just a phrase used on the web site or mailing
list announcement.

My primary request is that before we mark a branch as stable, we have
numbered development releases (not automated daily snapshots). Earlier
development releases will _not_ be "stable candidates". The specifics of
naming those development releases are less important.

HTH,
 
Alex.
Received on Thu Sep 25 2008 - 14:40:43 MDT