Henrik Nordstrom wrote:
On tor, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:
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.
No, it's simply that, but keeping the "PRE" state and reflecting this in
the numbering by using .0.X. The other states are dropped from the
numbering.
3.1.PRE1 -> 3.1.0.1
3.1.PRE2 -> 3.1.0.2
3.1.STABLE1 -> 3.1.1
And that we keep an indication on the web site on which releases is
currently considered stable for production use. (I would guess usually
the latest release + maybe one or two patch releases back, depending on
what bugs have been fixed)
Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N
Well, I'm a little doubtful but can't argue against that yet.
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.
How?
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.
There will likely be a couple of iterations from the branchpoint until
we are happy to label the release stable. My estimate is 2 such
releases.
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.
The RC indication is NOT part of the numbering. It's a process. If a
release candidate fails for some reason then that release never gets
promoted to stable and we move on to the next number.
Yes. Still worried that people are mixing the trunk/before
stable1/post-stable1 timespans and what can/can't be done.
But will leave it and see what happens when we trial this.
Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE9
