“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.
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…
O_o
Yep, my memory serves me right.
From http://lkml.org/lkml/2005/3/2/247
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]
Ahh right. hehehe
also, thanks for clearing that up.
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.
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.
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.
Let’s not forget that Windows 7 is actually 6.1… Even more amazing…
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?
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.
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.
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…
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.
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
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
…
Well TeX add one more digit to Pi at every release
http://en.wikipedia.org/wiki/Software_versioning#TeX
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
I think daily build recently changed to Firefox 7 I think because Mozilla started releasing Firefox 5 Betas
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.
There also some prominent linux’rs that propose the date based version number scheme… like Linux 2011/11/25
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?
“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.
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.
“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.
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.
I understand your point, but I fully expect to still be driving my 1995 Toyota Tercel in 2020 when it becomes an “antique,” legally.
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.
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…
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
…backwards compatibility breakage.features.security/bugfix ?
“The numbers become too big” just sounds like a strange reason ton me.
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?
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.
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.
Release:
$RELEASESDALL+1
Maintainance:
$RELEASESDALL.N
Developement:
$RELEASESDALL.0.501+GIT
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.