On Wed, Mar 16, 2011 at 7:51 AM, Jim Henderson
1) introduce planning of major releases of openSUSE. 2) stop using major.minor version numbers of openSUSE.
I have sofar been advocating 1), but as the powers that be do not seem overly inclined to taking that path, 2) is the alternative. I would much prefer "openSUSE 27" with no implied meaning over "openSUSE 13.4" with an implied ".4" meaning of no value.
Arguably, though, there'd be no difference between 27 and 28, why not go from 20 to 30?
When it comes down to it, release versioning is more of a marketing exercise than it is a project management/product management exercise (versioning is important to identify changes in SVN, for example, but those revision numbers only have meaning in that they are a measure of timed events - commits - that show a progression).
<snip for brevity>
So from the standpoint of a marketing discussion, I agree, major.minor doesn't make much sense unless the user can actually discern the meaning of a particular change in version number. Otherwise it's arbitrary.
Jim --
One of my issues with major/minor is that we then have the pressure to conform to Major/Minor. The progression must be followed, but what if upstream have no major changes and nothing much is happening with the kernel? What constitutes 'major'? Is it seen as partisan to mark a significant development in one desktop or another? Can one major follow another immediately if some major development occurs? My impression is that often change is a gradual, almost organic process with a lot outside of our control. The 11.4 to 12 step could be regarded as a major/minor, or it could simply be an abbreviated incremental process. I gather it is seen somewhat as a step to 'major' but it concerns me that this means that to go to 12, we are actively looking for reasons to make it major (without stepping on KDE toes over Gnome SHELL, for instance). I worry about painting ourselves into a corner by formalizing the major/minor idea. Some sort of flexibility would need to be built in, possibly to the release schedule to allow for desktop or kernel delays. Not necessarily negatives but just a couple of issues that would need to be addressed if we went that way. I agree somewhat with Chuck; this is something that should probably resolved quite quickly. cheers, Helen -- IRC: helen_au helen.south@opensuse.org helensouth.com -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org