My two cents are that switching to a date-based version system would be the wrong move.

Linux has not been extraordinarily successful at penetrating the desktop market. Where a lot of Linux lives is in the datacenter or the server farm. And if I'm a corporate IT drone, I want to know what is a major, disruptive upgrade and what is a minor upgrade. If you give such a person a CD labeled 2.8.0, it will be viewed with much more suspicion than one labeled 2.6.40, and rightly so. If you give one labeled 3.0, it will be filed in the dustbin until those zeros have become twos. Nobody's going to deploy a dot zero in a production environment.

Thus, giving the kernel what appears to be a big version bump for what is effectively a minor upgrade is going to freak out a lot of IT guys for no good reason. I remember IT shops which still ran 2.4 back in 2005ish because 2.6 was still 'too new'.

(Whether this attitude is legitimate or not is another question entirely).

I doubt this is at all a valid theory in an age when everyone sane is deploying the kernel their distro vendor provides, and doesn't care what version number it is. The last time I saw a kernel being manually deployed on any scale was about a decade ago. I have no idea what kernel any of my servers is running; except that it is the latest update available from my distro provider.

If you give such a person a CD labeled 2.8.0, it will be viewed with much more suspicion than one labeled 2.6.40, and rightly so.

Why would the CD be labeled 2.8.0? It would be labeled RHEL 7 or Debian 7 or Ubuntu 12.4 LTS. It would not mention the kernel version at all.

Linux kernels have been stable at release for years. They don't do development releases anymore. They're all stable, incremental upgrades (there are development branches, but no devel releases that would ever make it into distributions or anything).

There are two categories of people - those who are sophisticated enough to know that linux kernels these days are all fairly mature, and, what the .stable branch is, and those who aren't and use the kernel supplied by their Linux Distributor, and will, of course, be coddled with an appropriately safe version brand. RHEL 6, Ubuntu 11.04, etc...

Neither of those groups will be negatively impacted by setting the kernel version to 2.8 (or 3.0)

Exactly. Most decent admins will be watching these lists and know the reasoning behind this decision.

As if an IT Drone will look at the kernel version numbers! They are probably just going to install whatever RHEL or SuSE gives them.

Sure, but then he has to decide which updates to apply. Kernel update 2.6.40? Sure, why not. Kernel update 3.0? Not a chance.

Enterprise distros don't really do kernel version upgrades and this problem would be short-lived anyway since 3.1 would come out three months after 3.0.

(Y'all may be amused to hear that IBM never releases x.0 versions at all; they go straight to x.1.)

Not every project treats version numbers the same way.

It's irresponsible of anyone paid to know this kind of thing to not be aware of how a project handles version numbers.

Linus is the kind of guy that would go to 2.8 just "because it's time" in his mind rather than some big feature jump. Whether or not a person agrees, it would be good for people to at least inform themselves.

I agree.

Not all of our customers live up to your standard, however.

I think it's great to have a date as version number. It indicates how 'old' it is.

Linux 2.6.0 is 8 years older than Linux 2.6.38. But it's hard to tell. Linux 2003.12 vs Linux 2011.04 tells it all.

> Nobody's going to deploy a dot zero in a production

I routinely deploy software right off the version control. Exhaustively tested but, still, "pre-alpha".

Thanks to google making beta cool, now dev and companies have stopped lying about something being 1.0 when it really should be 0.1 beta 0.1

Conversely: some companies call products 0.1 beta 0.1 when they really should be 1.0. To me, when you release something to customers generally, that's (at least) 1.0. Calling it "beta" seems like a disingenuous way of avoiding taking full responsibility for bugs.

I wouldn't call it disingenuous. Putting a Beta label on a product says clearly "may not always work, proceed at your own risk".

When you need add features faster than you can exhaustively (as in aerospace-grade) test them, it's an act of balance. It has to work well enough to be useful, but it also needs to have the coolest features.

And it's not like, say, Windows, after about a quarter of a century, has been fully debugged.

>switching to a date-based version system would be the wrong move

It already is, its just done with a "2.6." prefix.

> so that I can avoid having to make the -rc1 release from Japan using my slow laptop

Linus can't just shell into a faster machine somewhere?

We would like you to phrase it by abandoning the idea that "me-too" comments are somehow suddenly appropriate.

> but when the voices tell me to do things, I listen.

Either deeply terrifying or words to live by. I can't decide.

That's Linus' sense of humour showing through. If you like, you could see it as him listening to his wizardly maker's intuition.

There's also an article on Phoronix -> http://www.phoronix.com/scan.php?page=news_item&px=OTQ3N...

Linus should just drop the 2.6 prefix and go with "Linux 40" (like Solaris 10 is SunOS 5.10). Then the stable kernel releases can be "Linux 40.x".

Then he couldn't do an major redesign of the kernel interface and signal it in the version id.

Unthreaded view: http://comments.gmane.org/gmane.linux.kernel.mm/63589

It sounds like he is toying with 3.0 in the comments later on.

So 2.8.0 is not really going to be a feature release? Seems strange.

If you're familiar with kernel releases it seems pretty normal to me. There have been some really major features merged in normal 2.6.x releases. I think they gave up long ago on trying to decide when a feature is cool and/or big enough to constitute a big version bump. It seems likely that they would increment it just to mix things up, not because of features.

Though my personal preference eliminates the dots all together (except for post-facto stable release (e.g. 2.6.39.2)), so the kernel released next would be kernel 3, the kernel released 3 mo later would be 4, and so on.