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.
Order by: Score:
linux 3
by manjabes on Tue 24th May 2011 15:13 UTC
manjabes
Member since:
2005-08-27

Was linux 3.0 the version that was supposed to be a ground-up rewrite in visual basic that Linus would create in a mental asylum? Kind of remember such a promise from previous versioning schemes...

Reply Score: 0

RE: linux 3
by Laurence on Tue 24th May 2011 15:19 UTC in reply to "linux 3"
Laurence Member since:
2007-03-26

O_o

Reply Score: 2

RE: linux 3
by manjabes on Tue 24th May 2011 16:06 UTC in reply to "linux 3"
manjabes Member since:
2005-08-27

Yep, my memory serves me right.
From http://lkml.org/lkml/2005/3/2/247

< odd >.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
the kernel to be a microkernel using a special message-passing version
of Visual Basic. (timeframe: "we expect that he will be released from
the mental institution in a decade or two").

Reply Score: 2

RE[2]: linux 3
by saby on Tue 24th May 2011 16:26 UTC in reply to "RE: linux 3"
saby Member since:
2011-05-24

Yep, my memory serves me right.
From http://lkml.org/lkml/2005/3/2/247

"< odd >.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
the kernel to be a microkernel using a special message-passing version
of Visual Basic. (timeframe: "we expect that he will be released from
the mental institution in a decade or two").
"

The current suggestion is 3.0, 3.1 - so this does not contradict the above ;) [3.0.1 etc stable updates - are not from Linus]

Reply Score: 1

RE[2]: linux 3
by Laurence on Tue 24th May 2011 19:19 UTC in reply to "RE: linux 3"
Laurence Member since:
2007-03-26

Ahh right. hehehe

also, thanks for clearing that up.

Reply Score: 2

<animal> <integer>
by Verenkeitin on Tue 24th May 2011 17:03 UTC
Verenkeitin
Member since:
2007-07-01

Decimal version numbers are so 90's.

Nowadays everyone is doing version numbers close or above 10 and cool ones have an animal name to further confuse people.

Reply Score: 4

RE: <animal> <integer>
by helf on Tue 24th May 2011 17:50 UTC in reply to "<animal> <integer>"
helf Member since:
2005-07-06

They also change the primary number with every release to make it look like you are doing more work than you are *cough*chrome*cough*

Reply Score: 2

RE[2]: <animal> <integer>
by Zifre on Tue 24th May 2011 19:32 UTC in reply to "RE: <animal> <integer>"
Zifre Member since:
2009-10-04

They also change the primary number with every release to make it look like you are doing more work than you are *cough*chrome*cough*

I'm so tired of people complaining about version numbers.

To me, if project A is at version X, and they release a new version Y, as long as X < Y, I'm happy.

The only exception would be deceptively changing a scheme that was already in use, e.g. incrementing something that is supposed to be a major version number when it doesn't make sense.

But if someone wants to number the versions 1, 2, 3, 4, 5, 6, .... 143, I really don't see what's the problem with that.

Reply Score: 2

RE[3]: <animal> <integer>
by ebasconp on Tue 24th May 2011 20:04 UTC in reply to "RE[2]: <animal> <integer>"
ebasconp Member since:
2006-05-09

I'm also tired of truly inconsistent versioning schemas:

Windows 1.0; 2.0; 3.0; 3.1; 95; 98; me; XP; Vista; 7; 8.... come on!!!

The version number should show the user the "evolution grade" of a given software; having "2000" or "2011" does not say anything but "I have the last version of this software", though such is the first one to be released.

Reply Score: 3

RE[4]: <animal> <integer>
by stereotype on Wed 25th May 2011 04:15 UTC in reply to "RE[3]: <animal> <integer>"
stereotype Member since:
2007-04-06

Let's not forget that Windows 7 is actually 6.1... Even more amazing...

Reply Score: 2

RE[3]: <animal> <integer>
by ephracis on Tue 24th May 2011 20:10 UTC in reply to "RE[2]: <animal> <integer>"
ephracis Member since:
2007-09-23

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 Score: 2

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

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 Score: 2

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

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 Score: 2

RE: <animal> <integer>
by poundsmack on Tue 24th May 2011 17:50 UTC in reply to "<animal> <integer>"
poundsmack Member since:
2005-07-13

Seriously, I mean isn't Chrome at version 13 now or something? and didn't it get there in months? It's like dog years of something...

Reply Score: 2

RE[2]: <animal> <integer>
by Lennie on Tue 24th May 2011 20:46 UTC in reply to "RE: <animal> <integer>"
Lennie Member since:
2007-09-22

The stable version is a 11, 10 came out just before Firefox 4. Mozilla today pushed out the first Beta of Firefox 5 already. They intend to release Firefox 5 about 3 monts after Firefox 4.

Reply Score: 2

RE[3]: <animal> <integer>
by poundsmack on Tue 24th May 2011 21:01 UTC in reply to "RE[2]: <animal> <integer>"
poundsmack Member since:
2005-07-13

Ya, but when you go to, say FileHippo.com (love this site) and pull up the "technical" tab to see the release date of every version (both beta and stable), you see it all as super rapid fire: http://filehippo.com/download_google_chrome/

http://filehippo.com/download_google_chrome/history/

the only program I've ever seen more this quickly through solid number is a text editor I like called Tea: http://freshmeat.net/projects/teaforlinux

Which is at version 29 ;)

Edited 2011-05-24 21:02 UTC

Reply Score: 2

RE[4]: <animal> <integer>
by ephracis on Tue 24th May 2011 22:07 UTC in reply to "RE[3]: <animal> <integer>"
ephracis Member since:
2007-09-23

Google is not advertising the version number of Chrome, it is only used internally, by the upgrade engine and in conjunction with issue reporting. Thus, the only purpose of it is to be able to determine if X > Y.

I suggest they use the scheme N^N:

Chrome 1
Chrome 4
Chrome 27
Chrome 256
Chrome 3125
...

Or alternatively the scheme 1/N^2:

Chrome 1
Chrome Half
Chrome Quarter
Chrome Eight
...

Reply Score: 2

RE[5]: <animal> <integer>
by pclouds on Wed 25th May 2011 13:19 UTC in reply to "RE[4]: <animal> <integer>"
pclouds Member since:
2007-07-13

Or alternatively the scheme 1/N^2:

Chrome 1
Chrome Half
Chrome Quarter
Chrome Eight
...

Well TeX add one more digit to Pi at every release

http://en.wikipedia.org/wiki/Software_versioning#TeX

Reply Score: 1

RE[3]: <animal> <integer>
by stereotype on Wed 25th May 2011 04:22 UTC in reply to "RE[2]: <animal> <integer>"
stereotype Member since:
2007-04-06

At work I'm running Firefox 6.0a or something like that... If you run the nightlies that's what it reports as its user agent string...

Edited 2011-05-25 04:24 UTC

Reply Score: 1

RE[4]: <animal> <integer>
by Lennie on Wed 25th May 2011 17:04 UTC in reply to "RE[3]: <animal> <integer>"
Lennie Member since:
2007-09-22

I think daily build recently changed to Firefox 7 I think because Mozilla started releasing Firefox 5 Betas

Reply Score: 2

RE: <animal> <integer>
by Thomas2005 on Tue 24th May 2011 21:30 UTC in reply to "<animal> <integer>"
Thomas2005 Member since:
2005-11-07

Decimal version numbers are so 90's.

Nowadays everyone is doing version numbers close or above 10 and cool ones have an animal name to further confuse people.

To make things easy, Linus should use a year.month.update scheme so he doesn't have to worry about when to bump the major/minor versions. As long as he doesn't release two kernels in the same month then this will work.

Reply Score: 1

date based
by fran on Tue 24th May 2011 18:14 UTC
fran
Member since:
2010-08-06

There also some prominent linux'rs that propose the date based version number scheme... like Linux 2011/11/25

Reply Score: 3

RE: date based
by sorpigal on Tue 24th May 2011 19:24 UTC in reply to "date based"
sorpigal Member since:
2005-11-02

I don't see that as very likely. It's even more confusing over the long term. Think about what happens when you're running RHEL15 in 2026 based on Linux 2019.01.25 with RH patches released yesterday. Is e.g. 2019.01.25-rhel2026.05.24-blah really a good way to go?

Reply Score: 3

RE: date based
by Alfman on Tue 24th May 2011 21:09 UTC in reply to "date based"
Alfman Member since:
2011-01-28

"There also some prominent linux'rs that propose the date based version number scheme... like Linux 2011/11/25"

That's what I use to label my software releases. The numbers aren't usually meaningful anyways, today software gets updated with new features all the time.

Version numbers often seem to be more about marketing than anything else.


But please don't use '/' characters!


How about "Linux 2011-11-25-mainline-stable"?
For typical users, who couldn't care less, it might be truncated to "Linux winter 2011", would this be bad?

A: Is your hardware supported under Linux?
B: Yes, a driver is available for Linux 2011, September and up.

Reply Score: 4

RE[2]: date based
by ggeldenhuys on Tue 24th May 2011 21:50 UTC in reply to "RE: date based"
ggeldenhuys Member since:
2006-11-13

How about "Linux 2011-11-25-mainline-stable"?
For typical users, who couldn't care less, it might be truncated to "Linux winter 2011", would this be bad?


Yes, because there are people like myself living in the southern hemisphere, where November is summer, not winter. :-)

Using years as a version number just seems bad to me. That will make software very quickly dated. Example, running Windows Server 2008 in the year 2011. That makes windows sound very old and outdated. Now compare that to saying Windows Server 7 in the year 2011 - that doesn't sound old any more. Just a perception thing I guess. ;-)

I say, stick with major.minor numbers and be done with it.

Reply Score: 2

RE[3]: date based
by Alfman on Wed 25th May 2011 01:08 UTC in reply to "RE[2]: date based"
Alfman Member since:
2011-01-28

"Yes, because there are people like myself living in the southern hemisphere, where November is summer, not winter. :-)"

Gosh you're right!

"Using years as a version number just seems bad to me. That will make software very quickly dated. Example, running Windows Server 2008 in the year 2011. That makes windows sound very old and outdated."

I honestly don't see how this is a problem?

"I say, stick with major.minor numbers and be done with it."

The arbitrariness doesn't bug you? At least the date gives us an idea of the age.

My car is a 2.36 Toyota Corolla.

Reply Score: 2

RE[4]: date based
by ggeldenhuys on Wed 25th May 2011 09:58 UTC in reply to "RE[3]: date based"
ggeldenhuys Member since:
2006-11-13

The arbitrariness doesn't bug you? At least the date gives us an idea of the age.

And with the "age" part one might get the idea that MySoftware 2008 running in 2011 is: old, outdated, obsolete etc.. But that could all be false ideas. Maybe the software is just plain rock solid due to 20 years of development history - thus no bugs and no new releases are needed.

Now if they used major.minor version numbers, you don't get that false sense of outdated software.

As for your comparison with cars... well cars age year-on-year. They get used and abused, so knowing the age is more important, hence the seasoning for using a year with the model name. We know it is pretty much fact that a 1995 model car will be pretty unreliable today.

A piece of software released in 1995 is just as reliable then, as it is today. I know of lots of [mainframe] software written in the 80's, and still being used today. Hence the year versioning doesn't work with software.

Bottom line, use what you feel is right. It's just a version number after all. ;)

Reply Score: 2

RE[5]: date based
by cmchittom on Wed 25th May 2011 12:55 UTC in reply to "RE[4]: date based"
cmchittom Member since:
2011-03-18

We know it is pretty much fact that a 1995 model car will be pretty unreliable today.


I understand your point, but I fully expect to still be driving my 1995 Toyota Tercel in 2020 when it becomes an "antique," legally.

Reply Score: 1

RE[2]: date based
by Delgarde on Tue 24th May 2011 22:31 UTC in reply to "RE: date based"
Delgarde Member since:
2008-08-19

How about "Linux 2011-11-25-mainline-stable"?
For typical users, who couldn't care less, it might be truncated to "Linux winter 2011", would this be bad?


Yes, for two reasons. One, because summer and winter are reversed in the southern hemisphere. And two, because it's somewhat ambiguous whether "winter 2011" was released in January 2011, or in December 2011.

Reply Score: 2

RE[3]: date based
by lemur2 on Wed 25th May 2011 01:20 UTC in reply to "RE[2]: date based"
lemur2 Member since:
2007-02-17

"How about "Linux 2011-11-25-mainline-stable"? For typical users, who couldn't care less, it might be truncated to "Linux winter 2011", would this be bad?
Yes, for two reasons. One, because summer and winter are reversed in the southern hemisphere. And two, because it's somewhat ambiguous whether "winter 2011" was released in January 2011, or in December 2011. "

Where I come from, it doesn't matter if it was was released in January 2011 or in December 2011, it would still be called "summer 2011".

But you knew that.

The only date-based schemes that would work worldwide are "yyyy-mm-dd" or "yyyy-mm". These schemes have the added advantage that they sort correctly as ASCII strings.

Reply Score: 2

RE[4]: date based
by Delgarde on Wed 25th May 2011 03:15 UTC in reply to "RE[3]: date based"
Delgarde Member since:
2008-08-19

Where I come from, it doesn't matter if it was was released in January 2011 or in December 2011, it would still be called "summer 2011".


Likewise, but the original poster was talking about winter, so I stuck with his northern-hemisphere example...

[quote]The only date-based schemes that would work worldwide are "yyyy-mm-dd" or "yyyy-mm". These schemes have the added advantage that they sort correctly as ASCII strings. [/q]

Well, Ubuntu get away with using yy-mm for their version releases. Hopefully they won't regret that ninety years from now... ;)

Reply Score: 2

The anwer
by avgalen on Wed 25th May 2011 03:32 UTC
avgalen
Member since:
2010-09-23

This discussion might take longer than 2.6.40 or 2.6.41, but even Linux won't dare to release a 2.6.42 if it isn't the answer to everything

Reply Score: 0

What's so bad about...
by Neolander on Wed 25th May 2011 05:24 UTC
Neolander
Member since:
2010-03-08

...backwards compatibility breakage.features.security/bugfix ?

"The numbers become too big" just sounds like a strange reason ton me.

Reply Score: 1

RE: What's so bad about...
by Alfman on Wed 25th May 2011 07:08 UTC in reply to "What's so bad about..."
Alfman Member since:
2011-01-28

Neolander,

"...backwards compatibility breakage.features.security/bugfix ?"

The trouble is, just about every version of the linux kernel breaks things at the source level.


I patch the kernel with AUFS because I need a union FS. However Linux maintainers have steadfastly refuse to incorporate any unionfs into the kernel (which is a topic for a different debate).

So anyways, I always try compiling the latest version of AUFS against the latest Linux kernel, and most of the time it doesn't work because linux added new arguments, moved functions around, changed structures, etc. Generally the easiest solution is just to use an older kernel, but I once needed a newer kernel and had to hack the AUFS drivers to fit.


The kernel devs say this encourages people to contribute their code back into mainline (to relieve them of the maintenance burden), but what about all the code they reject?


Or do you mean userspace breakage? Have any userspace syscalls been changed since the beginning?

Reply Score: 2

RE[2]: What's so bad about...
by Neolander on Wed 25th May 2011 07:14 UTC in reply to "RE: What's so bad about..."
Neolander Member since:
2010-03-08

I think that in Linux's case, one should better look at the user space point of view, since they made it pretty clear that they didn't support third-party drivers.

As an example of user-space breakage, sound handling has heavily changed from 2.4 to 2.6 (OSS has been deprecated and gradually dropped). This has caused some issues in user space.

Reply Score: 1

It is all perspective really
by ameasures on Wed 25th May 2011 09:05 UTC
ameasures
Member since:
2006-01-09

Having used each major Linux edition since kernel 1.1 there is a growing part of me that is content that the passage of time isn't too clearly displayed.

Reply Score: 2

simple numbers
by Ulenrich on Wed 25th May 2011 11:59 UTC
Ulenrich
Member since:
2007-04-26

Release:
$RELEASESDALL+1
Maintainance:
$RELEASESDALL.N
Developement:
$RELEASESDALL.0.501+GIT

Reply Score: 1

A good idea, but might be a better one
by ddc_ on Wed 25th May 2011 15:41 UTC
ddc_
Member since:
2006-12-05

First of all, now it is important to break current release numbering, as it proved to be hard to destroy the current tradition, which is obviously senceless.

The best possible solution IMHO was to just drop them, but this idea was discussed on LKML and was rejected on voting.

The other good solution would be YEAR.RELEASE.PATCHLEVEL (2012.1.0 for the first release in 2012 (which is now 2.6.x), 2012.1.1 for the update of the 2012.1.0 release (which is now 2.6.x.1), 2012.2.0 for the second release in 2012 (2.6.x+1) and 2013.1.0 for the first release in 2013 (2.6.x+(n=6) now).

While it doesn't really make much sence (a glance at kernel.org will tell which release is the current), it still is less senceless then YEAR.MONTH.RELEASE and less error-prone then days since Epoch (which is (a) a long number and (b) potentially limited in lifetime untill the end of current Epoch).

At the same time, just incrementing some digit in version number still isn't enough until some policy is settled (when the next increment has to happen and so on). Until this is done, no change would really make any sence - the numbering isn't all that important.

Reply Score: 1