[opensuse-project] Re: openSUSE versioning scheme (was Re: [opensuse-factory] Re: [opensuse-buildservice] Can we please get ARM builds for 11.3+1?)
On Saturday 03 July 2010 10:11:48 Vincent Untz wrote:
(I'm setting Mail-Followup-To to opensuse-project, since that's where this discussion should happen, but I agree we might want to wait for the end of the strategy discussion)
Le samedi 03 juillet 2010, à 09:10 +0200, Martin Schlander a écrit :
Fredag den 2. juli 2010 17:05:06 skrev Andreas Jaeger:
On Friday 02 July 2010 16:56:04 Thomas Schmidt wrote:
Shouldn't we call this 12.0? Reassigning the features afterwards would be additional work.
Naming of the next release is a separate discussion we might have. I'm opposed to both 11.4 and 12.0 and look forward to great proposals,
Let's not get too creative here. No funky codenames! :-)
We actually have code names, and it's the shades of greens. 11.3 is Teal. We just don't advertize this -- yet. (I think we should).
We should go for a simple numbering scheme, that doesn't cause the confusion that the old one has (a lot of people give different meanings to the numbers, even though they don't mean a thing - other than of course x.1 meaning "unusually buggy").
Either do it the Fedora way. openSUSE 12, 13, 14 etc.
Or the Mandriva way 2011.0, 2011.1, 2012.0 etc.
(Or the Ubuntu way, except that it doesn't work well with the next version which would be 11.03: 11.03, 11.12, 12.07)
One technical side of the decision that was pointed out in an earlier discussion is that we want to keep some suse_version compatibility. That means we still need to have, somehow, 11.3 < $nextversion. I'm unsure if it's really a hard limitation, though: we could do something like Solaris/SunOS where we have an internal scheme for technical purposes and an external one (Solaris 10 == SunOS 5.10). It makes things a bit complex, though, so there has to be a really good reason to do so ;-)
Or something similar. But maybe it would be best to await the conclusion of the strategy discussion before making any more major project decisions.
I just want to point out that the fact we'll get a decision for a strategy is also a good opportunity to change the versioning scheme: it's a good way to signal the change in the project.
There are also other reasons to change it, like the fact that the current scheme is hardly understandable by many (most?), leading to the 11.4/12.0 confusion we're seeing.
What I would propose for now is to create a simple wiki page summarizing the current state with pros and cons for changing of the version number, and start collecting alternatives, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Sunday 2010-07-04 10:18, Andreas Jaeger wrote:
We actually have code names, and it's the shades of greens. 11.3 is Teal. We just don't advertize this -- yet. (I think we should).
We should go for a simple numbering scheme, that doesn't cause the confusion that the old one has (a lot of people give different meanings to the numbers, even though they don't mean a thing - other than of course x.1 meaning "unusually buggy").
Either do it the Fedora way. openSUSE 12, 13, 14 etc.
Or the Mandriva way 2011.0, 2011.1, 2012.0 etc.
(Or the Ubuntu way, except that it doesn't work well with the next version which would be 11.03: 11.03, 11.12, 12.07)
One technical side of the decision that was pointed out in an earlier discussion is that we want to keep some suse_version compatibility. That means we still need to have, somehow, 11.3 < $nextversion.
"Now featuring <productA> v2.20" ! "Now featuring <productB> v436" ! Which one would you be more likely to check out? Probably the first one, because the second's version number is so ridiculously high that it surely is not a major release anymore. Going by Solaris- or Fedora-style numbering means you are exactly doing route B, a vast speedup in counting numbers. Resolution: productA was gnome, productB was 'less'.
it's really a hard limitation, though: we could do something like Solaris/SunOS where we have an internal scheme for technical purposes and an external one (Solaris 10 == SunOS 5.10). It makes things a bit complex, though, so there has to be a really good reason to do so ;-) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le dimanche 04 juillet 2010, à 10:18 +0200, Andreas Jaeger a écrit :
What I would propose for now is to create a simple wiki page summarizing the current state with pros and cons for changing of the version number, and start collecting alternatives,
I didn't know where to put this in the new wiki without breaking the organization there, so I just created http://wiki.opensuse.org/User:Vuntz/openSUSE_versioning_scheme Feel free to tell me where it should live, or to just move it there :-) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Vincent Untz wrote:
Le dimanche 04 juillet 2010, à 10:18 +0200, Andreas Jaeger a écrit :
What I would propose for now is to create a simple wiki page summarizing the current state with pros and cons for changing of the version number, and start collecting alternatives,
I didn't know where to put this in the new wiki without breaking the organization there, so I just created http://wiki.opensuse.org/User:Vuntz/openSUSE_versioning_scheme
I'd like to comment on what you're describing as "Issues with our current versioning scheme".
* It is unclear to many people why it works this way, and many people aren't sure if what's after 11.3 is 11.4 or 12.0.
This is not an issue in the versioning scheme, this is an issue for whoever decides what the next version is going to be. When many people aren't sure, it's presumably because it has been decided.
* The jump from 11.3 to 12.0 means for many people that there will be big visible changes in the distribution, while the changes between 11.3 and 12.0 are of the same order of magnitude as the ones from 11.2 to 11.3.
Again, this is not an issue in the versioning scheme, this is an issue for whoever decides what goes in the next version.
* It's an occasion to break the link between openSUSE and SLE versions: people expect SLE 12 to be based on openSUSE 12.1 because SLE 11 was based on openSUSE 11.1 and SLE 10 was based on SuSE Linux 10.x. Another confusion that can be made is that SLE 11 SP1 can be named SUSE 11.1 by some people, which could be understood as openSUSE 11.1.
Is this really an openSUSE issue? The main issue I see in the current version numbering scheme is that we are not adhering to it. IF we're saying that it is impossible to adhere to, that would a good reason for a more appropriate scheme. -- Per Jessen, Zürich (24.1°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 06 July 2010 16:24:50 Per Jessen wrote:
[...] The main issue I see in the current version numbering scheme is that we are not adhering to it. IF we're saying that it is impossible to adhere to, that would a good reason for a more appropriate scheme.
Per, what do you mean with adhering to the current version numbering scheme? What is your expectation on it? Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
On Tuesday 06 July 2010 16:24:50 Per Jessen wrote:
[...] The main issue I see in the current version numbering scheme is that we are not adhering to it. IF we're saying that it is impossible to adhere to, that would a good reason for a more appropriate scheme.
Per, what do you mean with adhering to the current version numbering scheme? What is your expectation on it?
Andreas
Hi Andreas, I have always understood the openSUSE versioning scheme to be a major.minor scheme: A change in major number means significant changes to the base system. syslog, sysinit, cron, mail, kde, X, zypper, yast, etc - the key components without which we would have no system. A simple upgrade of those components should not cause a major number change, but like I just wrote, perhaps if we changed syslog to rsyslog, sysinit to upstart cron to anacron, yast2 to yast3 and kde3 to kde4, we would have a number of significant changes that together would cause a major number change. The minor number changes on every release. We all know that openSUSE has not exactly been working towards such a meaning, i.e. we have not been adhering to the versioning scheme. -- Per Jessen, Zürich (24.7°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Jul 06, 2010 at 05:38:35PM +0200, Per Jessen wrote:
Andreas Jaeger wrote:
On Tuesday 06 July 2010 16:24:50 Per Jessen wrote:
[...] The main issue I see in the current version numbering scheme is that we are not adhering to it. IF we're saying that it is impossible to adhere to, that would a good reason for a more appropriate scheme.
Per, what do you mean with adhering to the current version numbering scheme? What is your expectation on it?
Andreas
Hi Andreas, I have always understood the openSUSE versioning scheme to be a major.minor scheme:
A change in major number means significant changes to the base system. syslog, sysinit, cron, mail, kde, X, zypper, yast, etc - the key components without which we would have no system. A simple upgrade of those components should not cause a major number change, but like I just wrote, perhaps if we changed syslog to rsyslog, sysinit to upstart cron to anacron, yast2 to yast3 and kde3 to kde4, we would have a number of significant changes that together would cause a major number change.
The minor number changes on every release.
We all know that openSUSE has not exactly been working towards such a meaning, i.e. we have not been adhering to the versioning scheme.
Well, we do disruptive changes in every release. (Not always in the same area). It is kinda hard to point out a .0 release before hand. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Marcus Meissner wrote:
On Tue, Jul 06, 2010 at 05:38:35PM +0200, Per Jessen wrote:
Hi Andreas, I have always understood the openSUSE versioning scheme to be a major.minor scheme:
A change in major number means significant changes to the base system. syslog, sysinit, cron, mail, kde, X, zypper, yast, etc - the key components without which we would have no system. A simple upgrade of those components should not cause a major number change, but like I just wrote, perhaps if we changed syslog to rsyslog, sysinit to upstart cron to anacron, yast2 to yast3 and kde3 to kde4, we would have a number of significant changes that together would cause a major number change.
The minor number changes on every release.
We all know that openSUSE has not exactly been working towards such a meaning, i.e. we have not been adhering to the versioning scheme.
Well, we do disruptive changes in every release. (Not always in the same area). It is kinda hard to point out a .0 release before hand.
Hmm, I beg to differ - all it requires is planning. Many software companies manage to do that (more or less well). Just for the record - I'm not advocating that we have to keep the major.minor scheme. All I'm saying is - if we keep it, let's make sure it has some meaning. if we choose a new one, let's first define what its purpose is. (i.e. if it's just to tell the next from the previous release, a sequential number is sufficient). -- Per Jessen, Zürich (24.6°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Jul 06, 2010 at 05:52:41PM +0200, Per Jessen wrote:
Marcus Meissner wrote:
On Tue, Jul 06, 2010 at 05:38:35PM +0200, Per Jessen wrote:
Hi Andreas, I have always understood the openSUSE versioning scheme to be a major.minor scheme:
A change in major number means significant changes to the base system. syslog, sysinit, cron, mail, kde, X, zypper, yast, etc - the key components without which we would have no system. A simple upgrade of those components should not cause a major number change, but like I just wrote, perhaps if we changed syslog to rsyslog, sysinit to upstart cron to anacron, yast2 to yast3 and kde3 to kde4, we would have a number of significant changes that together would cause a major number change.
The minor number changes on every release.
We all know that openSUSE has not exactly been working towards such a meaning, i.e. we have not been adhering to the versioning scheme.
Well, we do disruptive changes in every release. (Not always in the same area). It is kinda hard to point out a .0 release before hand.
Hmm, I beg to differ - all it requires is planning. Many software companies manage to do that (more or less well).
Just for the record - I'm not advocating that we have to keep the major.minor scheme. All I'm saying is -
if we keep it, let's make sure it has some meaning. if we choose a new one, let's first define what its purpose is. (i.e. if it's just to tell the next from the previous release, a sequential number is sufficient).
True ... but with opensource as it is difficult ;) The most disruptive changes we did were just before SLE where openSUSE gained all the funny new features... So perhaps the .1 releases should better be .0s ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Marcus Meissner wrote:
On Tue, Jul 06, 2010 at 05:52:41PM +0200, Per Jessen wrote:
Marcus Meissner wrote:
On Tue, Jul 06, 2010 at 05:38:35PM +0200, Per Jessen wrote:
Hi Andreas, I have always understood the openSUSE versioning scheme to be a major.minor scheme:
A change in major number means significant changes to the base system. syslog, sysinit, cron, mail, kde, X, zypper, yast, etc - the key components without which we would have no system. A simple upgrade of those components should not cause a major number change, but like I just wrote, perhaps if we changed syslog to rsyslog, sysinit to upstart cron to anacron, yast2 to yast3 and kde3 to kde4, we would have a number of significant changes that together would cause a major number change.
The minor number changes on every release.
We all know that openSUSE has not exactly been working towards such a meaning, i.e. we have not been adhering to the versioning scheme.
Well, we do disruptive changes in every release. (Not always in the same area). It is kinda hard to point out a .0 release before hand.
Hmm, I beg to differ - all it requires is planning. Many software companies manage to do that (more or less well).
Just for the record - I'm not advocating that we have to keep the major.minor scheme. All I'm saying is -
if we keep it, let's make sure it has some meaning. if we choose a new one, let's first define what its purpose is. (i.e. if it's just to tell the next from the previous release, a sequential number is sufficient).
True ... but with opensource as it is difficult ;)
Very true, yes.
The most disruptive changes we did were just before SLE where openSUSE gained all the funny new features... So perhaps the .1 releases should better be .0s ;)
Yes, they should. In my experience, a .0 release is generally risky, whereas a .1 is a lot safer. (not just for openSUSE). -- Per Jessen, Zürich (24.5°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Jul 6, 2010 at 18:12, Per Jessen wrote:
The most disruptive changes we did were just before SLE where openSUSE gained all the funny new features... So perhaps the .1 releases should better be .0s ;)
Yes, they should. In my experience, a .0 release is generally risky, whereas a .1 is a lot safer. (not just for openSUSE).
A .0 release number has almost zero to do with any real "risk" with openSUSE. openSUSE .0 releases have really just been an arbitrary number.. and that's what this whole discussion is all about. Look at the confusion regarding the next openSUSE release... is it 12.0 or 11.4? No one knows... why? Because the criteria for a release of openSUSE version number is... what.. just the next number... and the release goes up to the next major number based on... what? I don't know... I haven't seen any measurable pattern other than that openSUSE never goes to x.5, and rarely to x.4.... so we had 11.0 instead of 10.4. Why wasn't it 10.4? Why not 10.5? I have worked in software development for years... new products are never released in a 0.x version. The 1.x version is a "demo" version for the customers, and the first full commercial release to the customer is 2.x or higher. Why? Because of the perception around the 0.x and 1.x release numbers. People are conditioned to believe that the dot zero release is a bad one full of bugs. Is the released software any different though? Nope, but the customer perceives it to be "better' because it's not a 0.x or 1.x release number. I honestly believe that this exact same self fulfilling prophecy applies to openSUSE releases. People see 10.0 or 11.0 and think.. oh no, it's a dot zero release, it's going to be bad... but.. it's no worse than any other random release of openSUSE. openSUSE has never, to my knowledge, really honestly released a true (to the definition) dot zero release. We've had absolute train wrecks for releases that weren't dot zero releases (although, they probably should have been dot zeros considering the new concepts and software they introduced that made them all wobbly).... so anyone that thinks a dot zero release of openSUSE is "bad" purely on the dot zero number is just buying into the whole myth surrounding it. A release is a release... it could be good.. it could be bad. If we were to call the next release 11.4... and it had serious issues... would anyone be jumping up and down yelling it's a dot four release and it's crap (well some might.. but). But.. if we called it 12.0 and released the exact same builds... and had the exact same issues... people would be hollering it's a dot zero... see we told you so etc etc. C. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
C wrote:
I have worked in software development for years...
Me too.
new products are never released in a 0.x version.
Hmm, I can think of a few. This might depend on the sector - I wrote mainframe system software. A .0 release was always good and very thoroughly tested, but still slated for early adopters.
I honestly believe that this exact same self fulfilling prophecy applies to openSUSE releases. People see 10.0 or 11.0 and think.. oh no, it's a dot zero release, it's going to be bad... but.. it's no worse than any other random release of openSUSE. openSUSE has never, to my knowledge, really honestly released a true (to the definition) dot zero release.
openSUSE has only had one .0 release sofar. SuSE Linux 7.0 and 9.0 were both succeeded by .1 releases that were much better. I think also 8.2 was a major qualitative improvement over 8.0. -- Per Jessen, Zürich (23.4°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (6)
-
Andreas Jaeger -
C -
Jan Engelhardt -
Marcus Meissner -
Per Jessen -
Vincent Untz