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) > >> 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. Regards Henrik
signature.asc
Description: This is a digitally signed message part
