Linked by Hadrien Grasland on Tue 24th May 2011 14:38 UTC, submitted by Debjit
Linux "So far. we have seen 39 development cycles of Linux 2.6 and the 40th is about to start. However, Linux 2.6.39 might be the end of the Linux 2.6 series. In an email, Linus Torvalds wrote that the numbers are becoming too big and he might [be] thinking of giving the next release a version number of 2.8.0. [...] In the ensuing discussion, Torvalds wrote that a version number of 3.0 is also a strong possibility", as a natural way to introduce a new numbering scheme where odd numbers are also used for stable releases and feature releases increment the second digit.
Thread beginning with comment 474386
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: <animal> <integer>
by ephracis on Tue 24th May 2011 20:10 UTC in reply to "RE[2]: <animal> <integer>"
Member since:

This. So much this!

I just don't get people complaining about version numbers. Google is even trying to downplay their version numbers, they never use them in press releases. The press, however, use them all the time. And every time the geeks complain.

Either the version number of an application never moves away from 0.X or it is inflation for extra PR, or people argue whether feature set S is large enough to justify N or M increase in the major/minor number (where N!=M of course). To much focus on numbers I say.

In my application, I've made an attempt to get away from all this version number criticism by using the UNIX timestamp. The current UNIX timestamp is 10 digits. I divided them as A.BB.CCC.DDDD which means that we'll be at version 2.0 at the year 2033. ;)

OT: Is he just going to move it up to 2.8 or 3.0 because X > 40 is a large number or is there going to be anything in code to correspond to this change?

Reply Parent Score: 2

RE[4]: <animal> <integer>
by Kalessin on Tue 24th May 2011 21:58 in reply to "RE[3]: <animal> <integer>"
Kalessin Member since:

For libraries, versioning schemes can matter a lot. Take glibc for instance. You have certain compatibility guarantees between 2.6.1 and 2.6.2 which don't exist between 2.6 and 2.7. And all bets are off between 2.x and 3.x. Certain types of changes are permitted in certain releases but not others. The versioning scheme matters a lot to compatibility with libraries.

Now, for applications, that's a whole other matter entirely. They don't have compatibility issues in the same way, so they don't necessarily need to have as rigid a numbering scheme. Ideally, whatever scheme they use should make some sense, but in the end, it's pretty arbitrary. But for libraries, it matters.

Reply Parent Score: 2

RE[5]: <animal> <integer>
by ephracis on Tue 24th May 2011 22:02 in reply to "RE[4]: <animal> <integer>"
ephracis Member since:

Of course libraries and anything exposing any sort of API matters since you (should) use a scheme to demonstrate ABI or API breakage.

But the above commenter was talking about the Chrome (and thus application) version numbers.

If we stay on topic, I am wondering if Linus will change the scheme for Linux. Since Linux exposes APIs the scheme matters.

Reply Parent Score: 2