Hacker News Reader

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.