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.
