Hi Andrea: Thanks for the clarification.
Currently trunk is 3.9.3, and and branch-3.9.x is 3.9.2 so if I want to make a development release for either I would just append .svnXXXX_bli and that's it? I think as long as we have an upgrade path between the development RPMs and the released RPMs then I'm good. Cheers, Bernard On 8/18/07, Andrea Righi <[EMAIL PROTECTED]> wrote: > 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
