- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
openSUSE Leap 42.1 Is Based on SUSE Linux Enterprise, Milestone 1 Ready for Testing
|
|
|
Comments (8)
My only problem with openSUSE Leap is their versioning scheme! Why such a high number? Methinks the developers might want to rethink how they version this OS.
Its a giant game. People like bigger numbers.
Everyone knows the higher the version number, the more advanced and reliable it is. Right?
10
Yes that's right. Firefox version 39 is light years ahead of Internet Explorer version 11. The version number tells all.
The really irritating thing is that the traditional "major.minor.version" numbering scheme is actually much more informative.
I'm about to release a commercial software package. I think I will start with version 88 rather than 1.0.
The first update will be version 207, followed by version 3255.
I bet the updates will sell well as everybody will think that they must have major improvements due to the large version number changes.... ;-)
The first update will be version 207, followed by version 3255.
I bet the updates will sell well as everybody will think that they must have major improvements due to the large version number changes.... ;-)
the pike programming language is doing something like that. during development the version is bumped every few days, but not every version is released, so we got 7.8.700, followed by 7.8.866. i think the first 7.8 release was 7.8.66.
i disagree that the major.minor.version scheme is more informative. it can be, but only of the change between versions is consistent. in many cases, major.minor.version scheme just leads to inflation. well, deflation actually. emacs is a major example. developers think that no change is significant enough to increase the major version. so emacs went to 1.12 when it switched to 13, dropping the 1.
take the pike example again. the change from 7.8.66 to 7.8.700 tells a different story than 7.8.700 to 7.8.866. (ok, there were some more releases, but you get the idea)
now imagine the releases were 7.8.1, 7.8.5 and 7.8.6. same scheme, different story.
what's more, 7.0, 7.2, 7.4, 7.6 and 7.8 were all major releases of different degree. all of them had significant improvements that i would not count as minor. fortunately the developers agreed that the next release will be 8.0, because if it was going to be 7.10 we'd never reach version 8. the same problem happened before when pike releases were 0.5, 0.6 and 0.7. 0.7 was then renamed to 7.0 to counter the deflation.
but it depends on how you look at it.
pythons versioning for example is a lot cleaner.
if the difference between pike 7.6 and pike 7.8 is major, then the difference between python 2 and python 3 is earth shattering. for a programming language however, earth-shattering is not good, and the slow transition shows that. (i do prefer python 3 myself. it is just unfortunate that this switch was needed, but that's beside the point)
firefox for example, slowly and steadily changes. i don't think it had any changes significant enough to be called major in a long time. it's all an accumulation of small changes. so a single linear increasing value makes sense.
the kernel is now similar, and a single number would suffice for it.
the compromise of increasing the major version every 10 or 20 releases is workable too. just imagine forefox 39 as 3.9, then 4.0, etc... not really much different.
greetings, eMBee.
i disagree that the major.minor.version scheme is more informative. it can be, but only of the change between versions is consistent. in many cases, major.minor.version scheme just leads to inflation. well, deflation actually. emacs is a major example. developers think that no change is significant enough to increase the major version. so emacs went to 1.12 when it switched to 13, dropping the 1.
take the pike example again. the change from 7.8.66 to 7.8.700 tells a different story than 7.8.700 to 7.8.866. (ok, there were some more releases, but you get the idea)
now imagine the releases were 7.8.1, 7.8.5 and 7.8.6. same scheme, different story.
what's more, 7.0, 7.2, 7.4, 7.6 and 7.8 were all major releases of different degree. all of them had significant improvements that i would not count as minor. fortunately the developers agreed that the next release will be 8.0, because if it was going to be 7.10 we'd never reach version 8. the same problem happened before when pike releases were 0.5, 0.6 and 0.7. 0.7 was then renamed to 7.0 to counter the deflation.
but it depends on how you look at it.
pythons versioning for example is a lot cleaner.
if the difference between pike 7.6 and pike 7.8 is major, then the difference between python 2 and python 3 is earth shattering. for a programming language however, earth-shattering is not good, and the slow transition shows that. (i do prefer python 3 myself. it is just unfortunate that this switch was needed, but that's beside the point)
firefox for example, slowly and steadily changes. i don't think it had any changes significant enough to be called major in a long time. it's all an accumulation of small changes. so a single linear increasing value makes sense.
the kernel is now similar, and a single number would suffice for it.
the compromise of increasing the major version every 10 or 20 releases is workable too. just imagine forefox 39 as 3.9, then 4.0, etc... not really much different.
greetings, eMBee.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post