Slashdot Mirror
Linus on Kernel Version Numbering
walshy007 writes "In a recent thread it was asked what it would take for an 'unstable' 2.7 development tree to be created, to which Linus replied:
'Nothing. I'm not going back to the old model. The new model is so much better that it's not even worth entertaining as a theory to go back. That said, I _am_ considering changing just the numbering. Not to go back to the old model, but because a constantly increasing minor number leads to big numbers. I'm not all that thrilled with "26" as a number: it's hard to remember. I think the time-based releases (ie the "2 weeks of merge window until -rc1, followed by roughly two months of stabilization") has been so successful that I'd prefer to skip the version numbering model too. We don't do releases based on "features" any more, so why should we do version _numbering_ based on "features"?'"
version 2.0 ...
Linus... has... jumped the shark. The number versions... his version control insanities... He's no longer Linux's greatest advantage. He's now doing more to hold back the community than anything else. (dear god this is going to hurt the karma)
Modding Trolls +1 inciteful since 1999
What did it ever do to you?
Besides, it's accomplished a lot:
In mathematics
Inherent mathematical properties
Twenty-six is a composite number, its proper divisors being 1, 2, and 13. 26 is the only number between a square number and a cube number, the numbers being 25 (5 squared) and 27 (3 cubed). This was first proved by Pierre de Fermat.
It is the 7th distinct biprime (2.13) and the 5th with 2 as its lowest non-unitary prime factor. The aliquot sum of 26 is 16 with an aliquot sequence of 8 members; (26,16,15,9,4,3,1,0), leading to 0 through the prime 3 the 6th composite number so to do and so the sixth member of the 3-aliquot tree.
There is no solution to the equation Ï(x) = 26, making 26 a nontotient. Nor is there a solution to x - Ï(x) = 26, making 26 a noncototient.
In the classification of finite simple groups there are 26 sporadic groups.
Properties of its positional representation in certain radixes
Twenty-six is a repdigit in base three (222) and in base twelve (22).
In base ten, 26 is the smallest number that is not a palindrome to have a square which is (26^2=676).
Twenty-six is the number of five-digit prime quadruplets, the first of which is {13001, 13003, 13007, 13009}[1].
In science
Astronomy
Instead of wondering what to label things, how about getting some drivers for linux so that it will work with my printer for example ?
Linus' idea to switch to date-based version numbering seems excellent to me. From a psychological perspective, humans have difficulties with numbers, especially larger numbers. Also, a purely incremental numbering system without any external relationships (let's call it "semantic anchors" or something) are just that: numbers. By using dates we tie in with an already establish cognitive category which not only tells us the version but also how old it is. Since we Linux folks are usually very conscious about keeping up-to-date (at least the /. crowd) it would be a good and automatic reminder of the state of our system. That is, we use the "date obsolescence effect" (the reason Microsoft stopped naming their software after the year released) to the advantage for security rather than the disadvantage of negative sales.
The beauty of open source is that if you miss the odd-kernel numbering system more, you can fork the kernel and make your own! Yay! Enjoy maintaining both a stable and experimental code tree, constantly backporting important security fixes and features everyone wants, when you could just be modifying only one tree. Hope you have lots of free time!
This doesn't seem like breaking news to me. It's not even like he's talking about ceasing to use a naming scheme. The scheme is no longer used, now there's just a name. And the name is just a number, which no longer has any (other than historical) relevance. That's all we're talking about, in fact: Getting rid of a vestigial number.
Er, you don't do a release for specific "features," but once the release has been made, customers rely on knowing what "features" are (or are not) in the release they're using. There should be a sane and rational comparison rule to know if one version is newer (and likely to have more good "features" and fewer bad "features") or not. Ubuntu uses dorky names but anyone who knows the alphabet and the comparison rule can at least decide if "Beaver" is older or newer than "Walrus." I don't care what the kernel uses, but it should be something people can figure out the ordering.
Hey, I heard the Parameterized Ultra-Fair Order One Irreversible Hypoxic Process Scheduler is in the newest kernel. Wait, is that in 2.6.43.-12b34_+omicron-rc6, or not?
[
It is in part semantics, but at the same time it also represents the core not ostensibly having a bugfix-only branch. Distributions fill in the gap there to an extent. But it does reflect a departure from a lot of common practice of having a branch to follow for those content with featuresets, but needing the security and bug fixes too. As of the no-2.7 branch, this was already the case, this truly is just semantics. But the 2.7 decision was about more than semantics.
XML is like violence. If it doesn't solve the problem, use more.
For once I would like to see some linux kernel documentation in the code or elsewhere. Most comments are outdated and there is a definite need for 'programmer's guide' and also a kernel developer's guide. The books are getting outdated within a Linux kernel maintenance release window.. let alone a major release.
... EA uses dates (specifically the year) in the product names to make sure that you know that the NBA Live, Madden, etc ... you are currently playing with is already obsolete and that you need to purchase the new one which is more or less the same game with a few tweaks here and there.
Well, at least with the kernel, it gave me an idea of whether I ought to expect a program to run with few problems, require recompiling to work with few problems or require porting and compiling to work with few problems.
_I_ _Really_ _hate_ reading Linus' _email_ with all _his_ _underlining_ for emphasis!!!_-_-_-_ _REALLY_!
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
Move TCP/IP out of the kernel!
Why isn't it possible using the current interface
to write a user level protocol similar to TCP on
top of UDP? Why is UDP support force to have
poorer performance than TCP?
PS: Picture sending UDP packets to various hosts;
you need an interface to cut through the host
lookups which is what the TCP code in the
kernel has (let the user supply everything!).
Let's not have a 2.6.30, let's call it 3.0
El Tonerino
(because surely someone must care)
If the 2.6 is not going to change, drop it, it's redundant.
So we're down to 26. I personally find a name like "Linux 28" to be cool. "Linux 41 was released today...". There's nothing wrong with big numbers: see udev.
The problem with date-based numbering is that when you go from 2008.4 to 2008.10, it looks like you missed a few releases. And if you pre-announce a release, you have to meet your deadline or else rename the release.
So they could do what Gentoo does - 2007.0, 2007.1, 2008.0, 2008.1, etc. But you still have the problem that every year, you lose count of how many releases have happened. Was there a 2007.2 or did we just go to 2008.0 because we missed the Christmas deadline due to that last-minute security bug?
They could reduce the problem by using a longer period, such as a decade. (At 6 months for a release, for example, the number will only reach 20, which is not large.) But that's somewhat arbitrary. Plus, being in the 0th decade, we don't want to have 2.6.30 be called 0.3.
To reduce the complexity on all that, just drop the dates, and what's left is a single big number. No dots, no multiple numbers, easy. Linux 112 is fine by me.
Can anyone help? I installed the 2.6.26 kernel on my pentium, but it keeps saying I have version 2.6.25999999999993 installed?
The main problem I have right now is the sheer frequency of new kernel releases. A new release comes out every 90 days or so and contains a ton of new functionality, renamed functions, reworked innards, etc. It is a nightmare trying to keep my product's kernel modules working seamlessly across all revisions (i.e. - things I am interested in like memory management, process management, etc are constantly changing).
If Linux wants to get serious about becoming the standard platform for enterprise services, then it is going to have to get back to "stable" or "platform" releases that only come out once or twice a year. Either that, or just designate certain iterations (2.6.9, 2.6.18, 2.6.23, etc) as the platform release around which developers like me can focus our compatibility and testing efforts.
This will likely be modded down.
Is it just me, or has the 2.6 series been less stable for anyone else? Even sticking with the version shipped with Ubuntu's release rather than constantly updating to the latest version I get the feeling that the recent 2.6 kernels just aren't as stable as kernels released under the previous development model.
Year.DayOfYear like a version today would be 2008.198. If you need to know how much changed from one version to another (usually by looking at how the version, minor-version, minor-minor-version numbers change) just read the stinking release notes. Bob
Labeling a release based on the date is not as useful as some people think. Sure, it lets you know which releases are newer/older, and it gives you a reasonable idea of which ones might be the most up-to-date, but it has some major drawbacks.
One of the problems is, if people can't remember a number like 26, I'm not sure how they are going to remember a number like 2008-07-16. Also, it forces people who want to know about kernels to become a history expert. Does anyone actually know off the top of their heads when 2.2 was released? Do you know for how many successive months 2.2 kernels were released? What about times when 2.2 releases were still being made alongside releases of later kernel versions like 2.4? When you have an arbitrary number like 2.2, you get a basic idea for what the program is. If you're given a date, you start to lose your idea of what program exactly we are talking about.
I like old style versioning, fixed in 1.45 sounds better than fixed in r1445 and impossibly better than fixed in ad92c0626ae7e9ef92df3dfa4c967d93.
The only sane reason to go to date based versioning is to distinguish between features and/or stability. If you're not doing that (as linus contends), you may as well ditch version numbers all together -- good luck with that!
--------humorous comment------>
_O_
|
_/`\_
you
(news report sometime around the year 2500) People everywhere are stocking up on food, water and buying up home generators. No one is sure what will happen with the next kernel release, now that the version number 2.6.~ will no longer fit with in the ~ byte memory space where it is stored in most computers. Experts are unsure exactly what will happen but some of the things which may stop working include the electric grid, airplanes and automated teller machines. On the plus side, computer technicians are finding it easier than ever to acquire jobs as companies scramble to switch to Mac OS XXX which though it is otherwise inferior has avoided this problem by incrementing it's major version number. Let's go live to the street and see what people have to say. Some random person: Well... I'm just about done, I have a month's supply of food, a generator and duck tape. I had to take out a second mortgage. It wouldn't be so bad if it weren't for the gas. It almost cleaned me out just getting here. I sure hope they come out with that biofuel stuff soon. I'm glad those flying cars never took off though, Windows crashed my engine 3 times just on the way to the store. It's a good thing I wasn't in the air!
* Drivers out of the kernel
* stable binary interface for drivers
My first reaction was this was an undercover M$ person or other proprietary type, that wants to hide their driver and not be bothered by the GPL.
Never trust a man wearing a coat and tie!
Not really just a user.
I am all for FOSS drivers but having to recompile a driver is a pain. Having the driver in the Kernel makes the hardware developers dependent on the Kernel maintainers. They have no control over when it gets into the Kernel.
I would even be happy if drivers that used the binary API where REQIRED to be GPLed.
Moving drivers out of the kernel.
Notice that I limited it to low performance devices. A driver in kernel space can take out an entire system. I think it is dumb that a bad serial port or printer driver can take down a system.
As far as wanting to keep drives proprietary. Not really but the current system hasn't prevented it. It just makes them a pain for the end user.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Kernel 2008.w29 would be a kernel that was released this week.
Sure, you can't say for sure if the next stable kernel will be 2008.35 or 2008.39, but is it really all that important? Hell, if 53 versions a year is too much, go for 2008.m07 instead.
On the plus side it makes it easy to figure out how old your kernel is - if that's important somehow.
We do not live in the 21st century. We live in the 20 second century.
1. Posting AC with a comment like that displays very poor judgement.
2. Why are you using a printer manufacturer that refuses to make available either a driver of their own creation or the documentation to write one?
3. Don't be cheap. Buy a new (or used office-class) HP and enjoy!
As an FYI, here's a quick run-down of recommended printer manufacturers.
1. HP Drivers compile on ARM and x86 and works beutifully. I assume then, it would compile on PPC too. Distro packages are widely available.
2. Epson has x86-only binary blobs inside a source code base that is tough to build on Debian. RPM's supported.
3. (Dead Last) Canon has been quite hostile to Linux not quite as much as Brother, but both should be avoided.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
You are missing the point. "Lots" is a subjective term, and you need a definition or benchmark to measure by. The benchmark for drivers and device compatibility is Windows, and compared to Windows Linux does not have lots of drivers. Linux supports only a very small percentage of the devices Windows supports.
And this is another point you missed. When most people talk about "lots" of driver support, there is an additional factor they use for benchmarking, and that is current hardware. Windows and its support of the newest and most obscure hardware is the benchmark for the term "lots".
I'm a Linux user myself and love FOSS. I really wish things were different in this area, but anyone taking an objective look at the situation has to admit that Linux does not have lots of drivers. The only way you can say it does is to make up your own arbitrary definition of what "lots" means, but then the other 99% of PC users who have agreed on using Windows as the measuring stick are going to call BS on you. Having to list as many caveats as you did and still concluding that Linux has "lots" of drivers smacks of fanboyism.
Beware of bugs in the above code; I have only proved it correct, not tried it.
2008-1, 2008-2, 2008-3 makes sense to me.
I couldn't care less whether a kernel was released in january or april,
so simple numbering would be my favorite.
That scheme is easy to memorize, you immediately know which one is older and it keeps the number short.
I propose Offset 2000 version numbers, i.e., "(y-2000).mm[.dd]". The first number is the year minus 2000, followed by "." and a two-digit month, optionally followed by "." and a two-digit day when there's more than one release in a month. So version 8.07 would be the first release in July 2008. If you made a later release on July 17, it'd be 8.07.17 (so if a project makes many releases in a month, you can again determine how old yours is).
Date-based version numbers have a lot going for them, because at a glance you know when it was released (and thus you can determine how old something is). If you choose the ISO order YYYY.MM.DD, the numbers sort very nicely; Debian packages often use YYYYMMDD for versioning. But there's a problem: full year numbers, or full dates in this format, are annoyingly large. For example, version numbers 2008.07.16 and 20080716 are painfully long version numbers to remember. That's not necessary.
So, use dates, but shorten then. Since nothing today can be released before 2000, shorten it by subtracting 2000. Note this is subtracting - there's no Y2K-like rollover problem, because the year 2100 becomes 100 and the year 3000 becomes 1000. The second number is the month; using a two-digit month means you don't have the ambiguity of determining if "2.2" is earlier or later than "2.10" (you would use "2.02" instead). If you need to disambiguate day releases (or you make additional releases in the same month), add "." and a two-digit day.
These version numbers are short, they're easy to compare, and they give you a clue about when it happened. Ubuntu already uses this scheme for the first two parts, so this scheme is already in use and familiar to many.
If you use a time-based release system, using this version numbering system is easy, and you can even talk about future releases the same way. But what if you release software based on when the features are ready, or want to talk about the system under development? You can't easily call it by the version number, since you don't know it yet, but that's not really a problem. In many cases, you can just talk about the "development" version or give a special name to the development version (e.g., "Rawhide" for Fedora). If you need to distinguish between multiple development versions, just give each of them a name (e.g., "Hardy Heron" for Ubuntu); on release you can announce the version number of a named branch (e.g., "Hardy Heron is 8.04"). This is more-or-less what many people do now, but if a lot of us used the same system, version numbers would have more meaning than they do now.
- David A. Wheeler (see my Secure Programming HOWTO)
I like big numbers like 26. From a marketing perspective I guess it's a little odd, but from a geek perspective I know that early adoption can be a bad idea if you're looking to depend on something, and so knowing at a glance whether I'm adopting something early or not is great.
As an example, if I see 2.6.26 then I know that they've done quite a lot of patching to get 2.6 and it'll be a heck of a lot more reliable than say 2.6.3 would have been.
Of course, it doesn't mean so much if you don't know whether those 26 releases were over 5 years (a sign of quality) or 5 minutes (a sign of poor coding!). It's better than big ugly dates as version numbers though, IMO.
Maybe something like a release *age* would be good, based on (date of current revision) minus (date of last major version). Linux Version 2.6@5y indicates something a bit more mature than 2.6@2d. This could get messy with things like 2.6@5y6m and 2.6:@5y6m-rev2-rc1 though.
How about two version numbers, a basic one for dummies/marketing and an advanced one for geeks?
I don't see why everyone is in an uproar over this. I also don't understand how one man can decide to change the way things are because "26 is a big number".
Personally, I like the numbering system. The current numbering system is very easy to understand. Changes in the Major version number (and I think this is obvious because it's called the Major version) are major changes that may cause certain functionality to become obsolete or unsupported. Minor version changes will most likely not cause many issues. And the last number (I call it Bugfix, Patch, or whatever) probably has no adverse affects unless you have an application that relies on a bug to function.
Why not use both a date and a version number so that users can A) tell how much change has occurred between releases, and B) how much time has passed or how old their kernel is.
that if a printer does not work in Linux (CUPS) it will much probably also not work in OSX (CUPS) :-)
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Comment removed based on user account deletion
Like hurricanes. Next comes release Brittany!
No, what is hurting Linux is that numbering is way to geeky. The next version shouldn't be 2.6.X. For more widespread adoption, we might try cutesy names like Fluffy Rabbit to attract more females and kids. Or for professional sounding names like Tranquil. Of even more generic like Balls. That would be hilarious in everyday conversation. "Today I installed a new set of Balls at work." Hey why is everyone leaving? Hello, is anyone out there?
Man, you totally forgot the logo. That damned penguin is way too threatening and doesn't make any sort of political message. What we need there is a stylized picture of a group of hippies standing in a circle holding hands. Also, we need more than new version names, we need a new name, period. Stop calling it Linux because that doesn't mean shit. What we need is to find some vaguely positive word, translate it into a language used in some third-world nation, and use that for the name. What the hell is the Sanskrit word for "awareness", or some shit like that? Can we use that for the name of our OS?
If I see a version number of 2.00, I can ASSume that there are significant changes from 1.X. Also, as an "ohoh" version, it's more likely to have bugs than 2.1.
A year-based version tells me when it was released, but not much else. Maybe there was a major change in August, and V2008.08.01 is an "ohoh" version.
Named versions tell me even less. I might ASSume that "Perfect Penguin" is later than "Ornery Onyx", but I don't know how much has changed, or how long it took to release.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
We're releasing regularly, it makes sense to tie it to the date. If we skipped a year, yeah, the jump from 2008.3 to 2010.1 might be a little confusing, but honestly, a year without a kernel release? If that happens I think we can safely say linux is either dead or perfect (security flaws always occur in widely used software, so I'd say the two are synonymous.)
It's my impression that a constant amount of development is going on, so it makes sense to tie it to years - between 2008 and 2009 a year's work of work was done. That's descriptive, and useful when comparing versions. Normal version numbers don't really tell you anything other than that someone decided to make a release, and I think saying how long the release took is the most clear way of saying how different the release is from the previous release. If oddities like different numbers of releases in a year throw you, just do hybrid version numbers. i.e.
2008.1_40 (First Release, 40th day of year)
2008.2_200 (Second Release, 170th day of year)
_O_
|
_/|\_
me
Self-taught networking expert FTW!
Just roll three d20's.
When ideas fail, words become very handy.
In the last few months I've seen numerous driver improvements come out. In the last year or two I've seen TONS
A few years ago, there was a lot of hardware I had that simply didn't work. Cardreaders, webcams, and various run-of-the-mill stuff was a major chore.
Those started to trickle in slowly but increasingly within the last year. A lot of them run better in 'nix now than windows.
I was still stuck with running workarounds like "ndiswrapper" for my broadcomm wireless card until a few months ago. But with the newer wireless drivers and some recent updates, suddenly the mainstream kernel driver works like a charm. No more ndiswrapper for my laptop.
Seriously, not everything works in linux, but a lot of stuff does, and a lot more stuff does these days (at an increasing rate of release/compatibility)
What if the kernel 2.2 was done this way? What would the latest security release number be? 2008.07.16? So how do you know that upgrading your (2.6 era) 2008.04.12 to the 2008.07.16 will kill all your applications?
Same thing going forward: if the ABI breaks and kernel calls change, how do you deal with security fixes of a date-based older and incompatible version?
"The way to fix this is to mandate that hardware manufacturers publish detailed specifications based upon which FLOSS drivers can be written."
Why?
Why should tell a hardware manufacture what they can and not do?
Because if I am their customer, then I want them to act in a way that serves my interests. That is part of what I want for my money. I understand that I can't expect full indulgence from every hardware manufacturer - but I want them to understand, when I buy a piece of hardware I also want to have all the information necessary to make use of it. That is the message I want to send.
If you don't want to send a similar message, that's your business. I won't tell you you should think otherwise.
Bow-ties are cool.
I think you should call him "Tom Riddle" and then arrange the remaining letters from "Lord Voldemort" (v, o, o, l, r) into something vaguely resembling a name...
Oh, wait, that's not a good selection of letters... and there's not an I in there at all. let's make it "I am Lord Voldemort".
So... I guess that would make him Tom Voolmar Riddle!
Bow-ties are cool.
I vote for an easy-to-understand version labelling system, based on the premise that everything is experimental and what matters is the nature of the code base:
This leads to the self-evident truth that all technology should be improved until it becomes Summer Glau.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You mean, drivers out of OS... because Linux is the OS... But I dont like the idea that there would be ABI for drivers.
But I think it should be get changed that driver against Linux X.y.z can be moved like that to other Linux distribution.
The y2k as a bug problem wouldn't occur. However why bother subtracting 2k when by y3k the users of the system would be facing the same damn problem that made you subtract 2k in the first place.
Don't introduce "I feel pretty" concepts into a versioning debate. Especially when they lead to the kind of arbitrary offsets you're proposing. All it does is push the problem off (which is exactly what the y2k problem was).
If you're going to go with dated versioning, then each major release date can become a support/maintenance branch. At this point you need to re-introduce _something_ to be able to identify the difference between
2008.01.01 (new upgrades)
and
2008.01.01 (maintenance fixes applied to 2007.06.01).
Personally I usually just keep the build number tagged onto the end of the version. Everyone else can demand what they want with the release name and the version name and everything else. I can look at the build number and know what version the trunk is on.
If a particular build needs to be flagged for maintenance and support it gets a branch then it gets arbitrarily numbered from the root.
ie: The trunk is 0. The first branch is 1. A branch of a branch would be 1.1 except I've never needed to go there.
The politicians and philosophers that want to apply their current version/release labels can do as they please. I just follow the natural count of the nodes on the tree. The numbers tell me where on the tree I am. The build number tells me how far I am from the root.
This means the build number gets duplicated in different areas of the source, but it's essential meaning is the same. You are this far from earlier points.
I personally think they should just go with 1.0, 3.1, 95, 98, ME, NT, 2k, XP, Vista, and 7. That would be much less chaotic.
The trick is that you have to buy hardware
This can pose a problem for people who aren't buying or building a new computer system but instead trying to switch from an old, soon to be unsupported Windows operating system to */Linux. It can also pose a problem for people who receive hardware as a gift.
So you had to a wait a year [for a printer to become supported]. Big deal.
There are plenty of models that linger without a driver for years, to the point where the manufacturer stops making them. What should I do to speed up the process of developing a driver for a Microtek ScanMaker 4850 USB flatbed scanner, which is still unsupported in SANE after several years? Or should I just buy a new scanner?
$50 is a moot number because consumers are not volume buyers. Let's check the facts.
Dell Inspiron 1420, Ubuntu,$449
Dell Inspiron 1420, Vista Home: $649
http://www.dell.com/content/topics/segtopic.aspx/linux_3x?c=us&cs=19&l=en&s=dhs
http://www.dell.com/content/products/productdetails.aspx/inspnnb_1420?c=us&l=en&cs=19l=en&s=dhs (starting price model)
Sooo... Facts prove my point. Microsoft is more expensive. Please adjust your beliefs to better reflect reality.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Instead of wondering what to label things, how about getting some drivers for linux so that it will work with my printer for example ?
Surely this is a CUPS problem, not a Linux problem?
Stick Men
Several slashdot readers have made comments like "I can easily upgrade from 2.6.n to 2.6.n+1 because not much will have changed".
This is all part of the delusion of version numbers. The changes between releases are only limited by how many can be squeezed into the merge window. With an increasing number of developers, and development tools that seem to be scaling the overall trend seems to be that the n+1 release is progressively more different that its predecessor. Here are the diffstats for the last few kernels:
2.6.15 -> 2.6.16 6721 files changed, 392461 insertions(+), 202469 deletions(-)
2.6.16 -> 2.6.17 6321 files changed, 416664 insertions(+), 308709 deletions(-)
2.6.17 -> 2.6.18 8972 files changed, 381890 insertions(+), 217058 deletions(-)
2.6.18 -> 2.6.19 8040 files changed, 515161 insertions(+), 291784 deletions(-)
2.6.19 -> 2.6.20 5825 files changed, 262475 insertions(+), 136162 deletions(-)
2.6.20 -> 2.6.21 6568 files changed, 319232 insertions(+), 175247 deletions(-)
2.6.21 -> 2.6.22 7620 files changed, 519591 insertions(+), 266699 deletions(-)
2.6.22 -> 2.6.23 7203 files changed, 406268 insertions(+), 339071 deletions(-)
2.6.23 -> 2.6.24 10209 files changed, 776107 insertions(+), 483031 deletions(-)
2.6.24 -> 2.6.25 9738 files changed, 777371 insertions(+), 404514 deletions(-)
2.6.25 -> 2.6.26 8676 files changed, 595389 insertions(+), 416139 deletions(-)
Date-based versions don't help me very much. What I need/want from a version number is a clue as to how big the changes are. Is this version just bug-fixes and I shouldn't see much impact beyond fixing those errors? Is this a version that's got some significant enhancements and changes but my existing configuration should convert over without too much trouble and, while I'm going to see some impact, it shouldn't break my workflow and documents/code too badly? Or is this a big change with a whole new way of looking at large parts of the system, where I can expect major things to be a lot different and to have to adapt most everything to the new way the world is? The standard 3-part version numbers give me that kind of hint (at least when the developers stick to that accepted interpretation of the parts).
So word 97 is word -3.07?
Mmmm...negative versions!
-- Political fascism requires a Fuhrer.
The funy thing is iron - the atom with 26 protons - is supposed to be the most stable. Atoms with less than 26 protons fusion into larger ones, and atoms with less than 26 tends to fission in smaller ones.
Year 3000 - is that the year of the Linux Desktop?
Don't go to a brothel if you want to buy broth
Unix Timestamp.
If the major version numbers are now obsolete, why not go with something like this:
ie: replace only ONE of the numbers with a date reference.
Yes, a new kernel might well not have any new features in it but it more than likely will have new or improved drivers for specific pieces of hardware as well as a few bug fixes.
This is no different to MS releasing a new patch or Service Pack or Apple doing their updates however the hell they do their updates.
Gentoo Linux - another day, another USE flag.
If they're going to change to date versioning, they should do it properly: Use yyyy.[m]m as the main kernel number, but since older stable kernels gets maintained you'd need an additional .s[table] number at the end, e.g. 2008.07.2 (second stable release for kernel released in july 08).
The problem with the stable number is that it defeats the whole purpose of using dates in the first place, as now the date only tells when the kernel was _first_ released, not when it was updated (how usefull is that?).
So do it properly, use a scheme like: yyyy.[m]m.yymmdd, where the last yymmdd is the actual release date. This creates names like:
2008.7.080710 -> Kernel released 10th july 08
2008.9.080902 -> Kernel released 2nd sept 08
2008.7.080904 -> Kernel originally released in july updated 4th september
With this scheme you can look at the version number and instantly know a) when the kernel was originally released (ca), and b) when it was last updated with bugfixes. (This does not work if there is more than one mayor release in a single month, but with release cycles > 2 months that's not going to happen anyway.)
It may not look pretty, but it's informative and usefull. My .02 anyway.
Life is Reality
E.g. when stable ext4 is out, increment 2.x --> 3.x and we have "Linux 3.0". Then just continue incrementing the second number (3,1, 3.2, 3.3, etc.) until something big comes up and "Linux 4.0" sees the light of day. :)
This is the best way because dates don't work well in version numbers (year change in the middle of a development cycle etc.) and they don't tell anything to the users. The traditional versioning scheme is the best. It just needs to be used properly (no need for four digits - three is enough).
Thank you for recommending linuxprinting.org. Is there a site with similarly detailed recommendations for the other devices in and connected to a PC that may need drivers, such as 3D video cards, 802.11g cards, and flatbed scanners?
Solaris