All software has version numbers. Even applications only released once still bear a 1.0 version by default.
The Linux kernel is no exception. It has a very detailed version number that looks something like this:
2.6.33.1
The way most developers would format this version number is:
[major].[minor].[point].[build]
But according to some Linux advocates, the format is actually:
[static].[static].[major].[minor]
So apparently the first and second digits never change? What if they do change? How do you tell someone there was a “static” version update when two digits both represent “static”? If this really is the case, then there have been over 33 of these so called “major” releases made in the past six years!
On most platforms, frameworks and APIs, breaking changes are only introduced in major releases; Python 2 to Python 3, for example. By calling point releases “major” versions, it effectively allows the kernel developers to introduce breaking changes as frequently as five times a year.
Naturally, the kernel defenders claim that the API changes are actually minor evolutionary updates in each of these “major” releases, even if they’re breaking changes. Why are supposedly minor changes constituting major releases? Service Packs in Windows don’t suddenly bump XP from version 5.1 to 5.2!
With a target moving this fast, it’s a wonder developers aren’t clamouring to develop for Linux so they can perform mandatory maintenance on all their applications every two months. Developer time is limited, most of them don’t want to be perpetually ensuring their applications still work after the API changes.
Comments
WeWillDoItOurWay(TM)
It's a bit like the Ubuntu numbering system. You'd think it follows the version/point system like most software, but no.
I mean, sure, I'm all for originality, but when you do it just to go upstream and defy *useful* convention, it's just lame. Kinda like teenage rebellion.
Also, Administrator, you might wanna add MoveTheGoalPosts to this!
Suggestion applied. Good call.
You're just being silly. You're assuming that 2.4.x.y is actually the same product range as 2.6.a.b. Of course it isn't! They're just being honest about the ABI/API fiasco. (Btw -- may I recommend BiannualForcedDeathMarch?)
I first worked with VOS at version 6.0.something in 1987. I last worked with VOS at version 13.something in 2002.
Fifteen years, and the original programs still (re)compiled, and worked.
Fifteen months would be a miracle in the Land of Loon.
@DrLoser (and anybody else), correct me if I'm wrong but AFAIK the problem in userland linux isn't source compatibility as much as binary compatibility, since they have this manic love for (constantly changing) shared libraries;
I think most of the time you can compile very old programs from source, but you can't expect to run an old binary successfully.
I'm not saying that's good (damnit, you can still run win16 binaries mostly flawlessly on WinXP), just pointing out.
I'd put money on my assertion that 50% or more of Linux software circa 2000 won't compile on Linux 2010.
I've tried it with a neat little GUI app showing process stats, which broke because the user interface to X broke.
I'd also suspect that anything pre libc.so.6 will no longer work, but I could be wrong on that one.
(And then again, of course, there's been massive changes in gcc since 2.95.)
Still, you're basically correct. I could accept all of that, if only the goddamn ABIs wouldn't flail about for no good reason.
So even the version format is unstable?
I think it's snowing in hell, because the next minor version of the Linux kernel is 3.0[1]. And yes, that's not a typo, it's really minor. In Linus' words:
"So what are the big changes? NOTHING. Absolutely nothing."
[1] http://lwn.net/Articles/445223/
And now we have Firefox 8. Yeah, it's only been a few months since Firefox 4 was current.
You must be signed in to leave comments.