Bernard Li wrote: > Dear all: Hi Bernard,
> > I would like to propose the following change to the versioning scheme: > > Currently, the minor version number denotes whether the software is > "stable" or "unstable". For example 3.8.0 is considered stable > whereas 3.9.3 is considered unstable. s/minor/major/, probably you mean the second digit... > > When we release development/testing RPMs for both stable/unstable > releases, we add the SVN revision number and perhaps append the name > of the developer who released it, so for instance if Andrea posted > some testing RPMs for 3.9.3 release, it would be call something like > 3.9.3svn4204_arighi. > > The problem with this is that you can never upgrade this version to > the release version when it comes out, because 3.9.3 < > 3.9.3svn4204_arighi. No, 3.9.3 will never come out. All the 3.9.3.* versions are reserved for development/testing releases (because 3 is odd). This means that the official version will be 3.9.4 (4 is even), that is > 3.9.3.* > I would like to propose the following: > > For releases with revision (third digit from left) version > 0, then > the development version will be the previous revision version plus > .99. For instance, if I am releasing 3.9.3 development RPMs, it will > be named 3.9.2.99svn4204_bli. In this case since 3.9.3 > > 3.9.2svn4204_bli, I can upgrade the RPMs. > > For releases with revision version = 0, you drop back one minor > version and append .99.99. So If I am going to release test RPMs for > 4.0.0, it will be 3.9.99.99svn4423_bli. This sort of breaks the > stable vs unstable thing, but it's just one corner case we have to > live with. > > This scheme is actually adopted by most open source software and Linux > distributions. > > Comments? We already discussed this topic here: http://www.mail-archive.com/sisuite-devel@lists.sourceforge.net/msg02815.html The result of the discussion can be found here in a better form: http://wiki.systemimager.org/index.php/Developer_Guidelines#Versioning Anyway, probably these are transition rules, Brian proposed to fully replace the minor version (3rd digit) with the svn revision number for testing/development releases and to have only a stable mainline (remove the "unstable" branch). I mostly agree with that, but the approach to replace the 3rd digit could lead to confusion in some cases, for example it's not so clear that 3.9.svn4053 (for example) is > than 3.9.0 for example (and actually we've 3.9.0). So in order to have a smooth migration we're still using the 3rd digit + svn version appended. To be honest I like also the current approach (and maybe it's the best approach), but probably starting from 4.x.x release we could move to the new versioning schema, so for example: 4.0.0 <- will be the next stable 4.1.svn5050 <- development/testing/unstable releaes (pre-release for 4.2.0) 4.2.0 <- next stable 4.2.1 <- maintenance (bug-fix) release 4.3.1 <- illegal version! :-) should be instead 4.3.svnXXXX, because 2nd digit is odd Obviously if you find a bug in this naming schema or if you have a better solution we can always change these rules. IMHO the disadvantage of your proposal above is that it breaks the stable/unstable concept, so I prefer the current method. Cheers, -Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ sisuite-devel mailing list sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
