I'm ok with that. -Brian
On 5/11/07, Andrea Righi <[EMAIL PROTECTED]> wrote: > Brian Elliott Finley wrote: > > I'm suggesting that we not replace the minor release number with the SVN > > version for *stable* releases. But that we *do* replace the minor > > release number with the SVN version + developer initials for the > > *development/unstable* releases. > > OK. > > > > > > > What about using a kernel style versioning? > > > > > > That is what we have been using, except that I guess the kernel people > > have recently changed the way they do versioning. > > > > Yes, they added the fourth number (extraversion) to release early new > versions > that includes only critical bug fixes. But, in our case we can simply use > the > third number for this. > > > * Do we need to differentiate between "official development > > releases" and "unofficial development releases". I'd say, if it's > > a development release, it's always unofficial. > > Agree. A development release will be not available from the official > repository (sourceforge). > > > And if we need to > > do a pre-release, we just do a developer release, and treat it > > like a release candidate. In other words, for unstable releases, > > always use the SVN version + initials in the third position (no > > fourth position ever). And for stable releases, always use the > > next incremental integer. As stable releases should only be > > versioned for bug fixes, I dont' see a need to do pre-releases of > > bug-fix releases. > > OK, it should be better IMHO to use an anonymous code for the unstable > releases > that we upload in the official repository. I mean, the latest unstable is > 3.9.0. > I wouldn't like to distribute 3.9.4058_arighi or 3.9.4058_bef, etc. > > Better to use for example 3.9.svn4058, that would be a release candidate for > 3.10.0, even if it's a bit misleading, because for a human it's not so clear > that 3.9.svn4058 is greater than 3.9.0... while it's more evident that > 3.9.1.svn4058 > 3.9.0. > > > > > So, this would look like: > > Stable mainline: > > 3.8.0, 3.8.1, 3.8.3 (the 8, as even, indicates stable) > > > > Unstable (no mainline vs. developer -- make all unstables "developer" > > releases. A release candidate could use "rc" as the developer initials, > > if desired): > > 3.9.4053_arighi, 3.9.4060_bef, 3.9.4072_rc > > > > Then the next stable release would be: > > 3.10.0 > > > > Next bug fix release: > > 3.10.1 > > > > Next development/unstable release (doesn't matter if it's from a > > developer branch, because the svn version has that inherent): > > 3.11.4073_bli > > So, in conclusion, I'm ok with everything except that I'd prefer to > introduce > the extraversion (fourth number) for development/unstable releases for now, > to > have a "smooth" migration from the old version style to the new one (since > we > have a 3.9.0 under the unstable branch). > > Maybe we can fully adopt to the new style as proposed by Brian starting with > 3.10.x... > > Other opinions? > > -Andrea > -- ------------------------------------------------------ Brian Elliott Finley Phone: 630.631.6621 gpg --keyserver wwwkeys.pgp.net --recv-keys 10F8EE52 ------------------------------------------------------ ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ sisuite-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
