Re: [RFC] 3.1 branching

From: Henrik Nordstrom <henrik_at_henriknordstrom.net>
Date: Thu, 25 Sep 2008 09:32:33 +0200

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

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

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

Yes. Which is an improvement from the current 1.5 year. (which btw
started when Squid-3 branched)

Regards
Henrik
Received on Thu Sep 25 2008 - 07:32:44 MDT

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