Why is the version number so darned high?!?
|
| Author | Content |
|---|---|
| cmost Jul 25, 2015 3:54 PM EDT |
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. |
| Jeff91 Jul 27, 2015 11:52 AM EDT |
Its a giant game. People like bigger numbers. |
| seatex Jul 27, 2015 8:09 PM EDT |
Everyone knows the higher the version number, the more advanced and reliable it is. Right? |
| the_doctor Jul 27, 2015 10:08 PM EDT |
10 |
| penguinist Jul 27, 2015 10:22 PM EDT |
Yes that's right. Firefox version 39 is light years ahead of Internet Explorer version 11. The version number tells all. |
| BernardSwiss Jul 27, 2015 10:27 PM EDT |
The really irritating thing is that the traditional "major.minor.version" numbering scheme is actually much more informative. |
| linux4567 Jul 28, 2015 11:25 AM EDT |
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.... ;-) |
| mbaehrlxer Jul 30, 2015 4:01 AM EDT |
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. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!