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 ------------------------------------------------------------------------- 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
