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.
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.
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.
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.
Alex has indicated his understanding of NO sub-numbering after X.Y.1,
which equates to no -RC.
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)
Yes, yes. I agree that 3.0 went badly before people got the momentum
going in PRE6.
Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE9
