Torvalds Polls Desire for Linux's Next Major Version Bump 199
jones_supa writes: Linus Torvalds made this post about Linux version numbering: "So, I made noises some time ago about how I don't want another 2.6.39 where the numbers are big enough that you can't really distinguish them. We're slowly getting up there again, with 3.20 being imminent, and I'm once more close to running out of fingers and toes. I was making noises about just moving to 4.0 some time ago. But let's see what people think. So — continue with v3.20, because bigger numbers are sexy, or just move to v4.0 and reset the numbers to something smaller?" To voice your opinion, the Google+ post allows you to discuss the matter and cast a vote in a poll.
Is semver too simplistic for kernels? (Score:5, Interesting)
Re: (Score:2)
Every version system is arbitrary. The entire point is utilitarian and supposed to be helpful in keeping track of which version you are using.
Re: (Score:3)
If the kernel doesn't fit the usual versions model, why not just go with the freakin' date?
Linux Kernel 2015-02
Re: (Score:2)
The solution for this problem is quite easy: don't release software with bugs!
Re: (Score:2)
It gets the version number the day it actually gets released. When it's still pending to be released you just refer to it as "the next version" or "the pending release" or whatever.
Re: (Score:3)
I'd prefer:
2015-12-27rc, 2015-12-29rc, 2016-01-02rc, 2016-01-06!
Re: (Score:2)
It's arbitrary now because nothing major has changed ever since 2.6. Before that, with 1.x, 2.0, 2.2, and 2.4, there were big architectural differences and drivers were not compatible between the releases. After the 2.6 changes, they stopped making large changes as everything had stabilized, and there was no more reason to make incompatible changes. Also, before 2.6, they had two tracks, a "stable" kernel and a "testing" kernel, where an odd number was used for the testing version. So there was 2.4.x wh
Re:Is semver too simplistic for kernels? (Score:5, Insightful)
Version Numbers in general are outdated for application. The line between a Major and Minor version is huge.
We have been on Mac OS X (10) for 14 years. with have been getting point updates over the time.
Microsoft during that time has had 4 Major updates (That is with the insane longevity of XP).
We have Chrome and Mozilla who for the most part dumped minor versions and we get a Major version every other week.
In my mind a Major Number should be when there is a large change to the system. Going back and rewriting a lot of code, adding/removing features. While the minor version is just a patch, giving better performance, but the core architecture is nearly identical. Still in my mind, there is a lot of subjective debate.
Re: (Score:3)
You hit the nail on the head. The problem, especially with mature platforms, is that big changes tend to not happen. We are not seeing any new bus architectures, nor are we seeing anything that fundamentally changes the kernel's architecture, so there are two schools of thought:
The first is to only bump up a major version number only if something radical happened, which the Linux kernel used to do (I remember back in the 1.x days, seeing 1.1.100.) Then there is bumping the major number routinely.
I'm of t
Re: (Score:2)
I'm going to take "non-technical people" and assume that means people who don't care about the kernel. And then I'll tell you that the version the number of the kernel is irrelevant because non-technical people don't even know what it is. They might know which distribution they're using. Maybe.
Re:Is semver too simplistic for kernels? (Score:4, Informative)
Version Numbers in general are outdated for application. The line between a Major and Minor version is huge.
We have been on Mac OS X (10) for 14 years. with have been getting point updates over the time.
Microsoft during that time has had 4 Major updates (That is with the insane longevity of XP).
It depends on what you are talking about. The internal version number for Windows 7 is 6.1.x (Windows 8.1 is v6.3). So if we are going by marketing-driven release numbers, then there have been 6 or so major Windows NT release since 1996 (Windows NT 4.0, Windows 2000, Windows XP, Vista, 7, 8). However, if you go by the engineering version number there have been just 2: Window 2000 was NT v5.0 and Windows Vista was NT v6.0.
And then there is emacs :) (Score:2)
We have Chrome and Mozilla who for the most part dumped minor versions and we get a Major version every other week.
And then we have emacs where they dropped the major version number (see cute wikipedia story)..
In my mind a Major Number should be when there is a large change to the system.
On topic: Lots of things have changed in the linux 3.x series. For example the kernel now supports docker out of the box (if I recall correctly). This was added and improved over multiple releases, but there is a big difference between 3.0 and now. IMO, it's totally valid to make a major release...
Anyways, at the end of the day, this doesn't matter. But it is so lovely simple that everybody can have an opinion a
Re: (Score:3)
I adopted a convention for my software: x.y.z
"x" changes if there are some major features or change how the software works.
"y" changes if there are some new features.
"z" changes if there are only bug fixes.
Keeps it simple, easy to remember, and users reacted very well to it since they can immediately tell how big of a release it is.
Re: (Score:3)
Thats the Semantic versioning convention:
http://semver.org/ [semver.org]
Re: (Score:3)
Re: (Score:2)
I'll be damned, I did not know this was a thing, I just came up with something that was logical, and served to communicate with user the nature of the release.
And you are right, this is not semver. I don't do backward incompatible changes, so the major number would never change thus the major number as specified in semver is useless for me. Nice to see it is pretty close though.
Re:Is semver too simplistic for kernels? (Score:5, Interesting)
I would argue for adding an extra decimal point: W.X.Y.Z
'W' - Major Release - reserved for significant rewrite/technology/architectural changes
'X' - New Feature Release - significant changes to existing architecture/technology
'Y' - Minor Release - minor changes to existing architecture/technology - could be for major bug patches, or other miscellaneous performance enhancements that we want to differentiate from previous releases.
'Z' - Patches - things that do not rise to the level of a full release - could be for minor bug fixes, or to track iterative evolution and re-factoring of a small component of the overall system. Having the extra number here would allow you to keep each individual decimal number smaller by selectively rolling the number above it without necessarily impacting your major release numbers - basically it splits up the last number - which seems to get a lot of use - into two numbers to spread the load.
Re: (Score:2)
I would argue for adding an extra decimal point: W.X.Y.Z
We did at some point, but users were not able to remember the full version number. People already have trouble sometimes remembering 3 numbers. They start telling you things like "I have the latest version", which they often don't, or confusing 10.0.1 with 10.1.0. 4 numbers makes the situation much worse.
Why is this important? because when someone sends you a bug report, you want to know exactly what version they are using. You may or may not have fixed the bug already, so having accurate version nu
Re: (Score:2)
We did at some point, but users were not able to remember the full version number. People already have trouble sometimes remembering 3 numbers. They start telling you things like "I have the latest version", which they often don't, or confusing 10.0.1 with 10.1.0. 4 numbers makes the situation much worse.
Why is this important? because when someone sends you a bug report, you want to know exactly what version they are using. You may or may not have fixed the bug already, so having accurate version numbers matter.
The fix for the human factors problem is to automate the generation of the bug report on the user's system such that it captures the version information for things critical to your app (e.g. kernel version, libraries versions, your application's version etc...). Have the application itself do this upon failure, and/or provide a tool to capture the requisite information after the fact.
Then, make it a policy not to accept bug reports without the appropriate error log data accompanying it (with clear instru
Re: (Score:2)
Makes it sound like what determines a version bump is somewhat arbitrary, are kernels just too complex for them to fit into a simple versioning convention?
More like the other way around, Linux doesn't ever make changes that break userspace so the first version number is pretty much set in stone, it should be 2.60 or so now really. I don't get it though, the only thing he's encouraging is to just code majorVersion >= 2 and if he ever does decide to break a userspace API everything will break. But since he hasn't done so in the last 19 years (2.0 was in 1996) I guess he figured that just won't be necessary, ever.
Re: (Score:2)
It used to be that around once a decade, the major version number got bumped up. 3.0 was released in 2011. What's the rush all of a sudden?
If you're going to change it, use something more sensible, like kernel-2015-05-20 rather than having arbitrary version numbers.
Why mess with v4.0? (Score:5, Funny)
Why not just skip directly to Linux 10?
Re:Why mess with v4.0? (Score:5, Funny)
You can't just skip over Linux ME, Linux 2000, Linux Vista, Linux XP and Linux 8!
Re: (Score:3, Funny)
Linux NT is the best. We can call it LiNT. Then wait for Mint to make a distribution based on LiNT.
"Do you run LiNT Mint?"
Re: (Score:3)
Please, oh please - can we at least skip over Linux Vista?
Actually, many years ago I tried to run Red Hat 6 (IIRC). I was new to Linux so I knew there would be a learning curve. But after a great deal of misery, I finally discovered that there was something fundamentally broken about the then-current version of GCC, and there was no possible way for a newbie like me to compensate. So, maybe that was the "Vista" moment of "the GNU/Linux system".
Since then, I've tried several Linux distributions and general
Re: (Score:2)
I doubt it will be. Sounds to me that Windows fits you just fine. That being the case, you have little incentive to really try Linux, so I don't think 2015 will be much different for you than any of the previous years. True Linux distros have gotten better and easier--Linux Mint would probably work for you right now out of the box without having to mess with browser plugins or tweaking audio. But you don't seem to have much motivation to try Linux, so much smaller issues are going to be stumbling blocks f
Re: (Score:2)
Good points. You seem to be confirming what I've long suspected: that things that seem easy on a system you have experience with, but seem hard on a system you don't have experience with, may be more a function of the experience than the system.
I remember many years ago when I was first learning Windows 95 that I had to go and ask experts a lot of questions on how to do things. Now it all seems so easy - except when Microsoft shuffles the deck chairs for no good reason. For example, I've just been forced
Re: (Score:2)
Or how about Linux 2015? And if another release comes out mid-year we can go with Linux 2015 R2?
Running out of toes? (Score:2, Funny)
Not quite sure (Score:5, Insightful)
I'm not really sure because I don't know if Linux adheres to Semantic Versioning [semver.org] or not (previous bumps in the major version number might suggest not). Semantic versioning doesn't work for every project but I am pretty sure that (if Linux used semantic versioning) that the next release would not introduce any incompatible changes to the API/ABI.
Re: (Score:2, Insightful)
No, the Linux kernel does not have adhere to Semantic Versioning. For one thing, it is backwards-compatible until the last user of an userspace ABI either dies or sleeps on the job long enough (a few months) to not notice it is going away in the latest kernel if someone doesn't speak up. There are exceptions to this, mostly related to how painful it is to keep a feature still working, but they are very rare.
Note: internally the Linux APIs/ABIs change all the time, and breaking anything and everything tha
Re: (Score:2)
Related to the above, I'm not even 100% sure if Torvalds' mantra of "WE DO NOT BREAK USERSPACE!" is the best course of action. If userspace needs breaking, then break it and bump the major version number, otherwise things could potentially end up as horrible as MS operating systems and their attempt at preserving that over time.
Re: (Score:2)
After 24 year, I think that if it were to become the MS monstrosity, it would have done so by now. Consider how many times the DOS/Windows kernel has been rebooted in that time.
Re: (Score:3)
After 24 year, I think that if it were to become the MS monstrosity, it would have done so by now. Consider how many times the DOS/Windows kernel has been rebooted in that time.
I'm not sure MS is really the right comparison here. They're actually fairly famous for never breaking userspace. I wouldn't be surprised if Calc.exe from Windows 386 ran fine on Windows 8. Device drivers are a different matter.
Re: (Score:2)
Only if you're running 32-bit Windows 8.
Cite? Last time I checked 64-bit versions of windows ran 32-bit software (or in this case 16-bit) just fine.
Re: (Score:2)
Sorry, you are wrong. 64 bit windows does not run 16 bit software.
Got it. So, you're stuck only running software written as early as 1995 on the 64-bit version of Windows 8. Otherwise you'll have to stick to the still-in-production 32-bit version of the product.
Clearly MS is abandoning too many customers here who are still using 8+3 filenames.
Re: (Score:2)
I've seen plenty of software break on newer versions of Windows. My point is that overall it is a lot rarer than you'd expect, and MS probably goes further than just about anybody to prevent it from happening.
What other OS will run 20 year old binaries without issue on a recently released version of the OS?
Re: (Score:2)
I'm not sure MS is really the right comparison here. They're actually fairly famous for never breaking userspace. I wouldn't be surprised if Calc.exe from Windows 386 ran fine on Windows 8. Device drivers are a different matter.
That would be IBM with mainframes since the 60s with what is now z/OS and can run applications from the 60s (I don't know how it was called before MVS).
Microsoft is just the opposite, the most important criterion for releasing a new version of DOS was that it broke Lotus-123.
Ok, I'll grant you the IBM mainframes. :)
I would distinguish between MS's treatment of its competitors with its treatment of everybody else. Also, that sort of stuff stopped being important after the 90s, mainly because they had no competitors left.
Re: (Score:2)
Re: (Score:2)
Indeed.
2.0 -> 2.2 -> 2.4 -> 2.6 all heralded major changes, while 2.6 -> 3.x did not.
I think there should have been one major lift (to 2.8?) in there with devicetree - that's a big change that introduces lots of potential incompatibilities and required changes to userland. But that one went in a minor number, which seems rather wtf to me.
My recommendation: Switch to 4.1 and go back to an odd/even system so 4.2 will be the next stable.
Also make a marker for whether a stable kernel is also desig
Re: (Score:2)
Switch to 4.1 and go back to an odd/even system so 4.2 will be the next stable.
Linus already decided the odd/even system was a bad idea, and he had good reasons for it. I don't think there's any way he'll go back.
Re: (Score:2)
Indeed I've never seen any compelling reason for it being a bad idea other than "Well, some distros were defaulting to the odd version because the stable one was missing so much stuff!".
The problem was that the odd-numbered versions weren't getting enough testing, so the real testing didn't happen until the even-numbered release. So the system seriously slowed the pace of kernel development without significantly improving stability.
Well, part of the reason for his CURRENT change is that there's not much stuff going on between releases, indicating that the pace of update is dropping so low that it would no longer be a problem.
You don't follow kernel development very closely, I see. :-)
Re: (Score:2)
The problem was that the odd-numbered versions weren't getting enough testing, so the real testing didn't happen until the even-numbered release. So the system seriously slowed the pace of kernel development without significantly improving stability.
True, and the solution to that should be that nothing except emergency fixes goes into the stable branch until it's tested in unstable.
And I disagree with the AC you replied to that Torvalds has god complexes. Not so - he's quite capable of changing his mind as situations change, which his change to discard odd/even is just one example of. He has made mistakes in the past, and will probably be the first to tell you. However, he's a leader type in that he's willing to make hard decisions even when they co
Re: (Score:2)
The problem was that the odd-numbered versions weren't getting enough testing, so the real testing didn't happen until the even-numbered release. So the system seriously slowed the pace of kernel development without significantly improving stability.
True, and the solution to that should be that nothing except emergency fixes goes into the stable branch until it's tested in unstable.
While that's not unreasonable, it really doesn't address the problem. The problem was that not enough people were running unstable, so it wasn't getting enough testing. I suppose slowing progress even further might have pushed a few more people to use the dev kernel... but I doubt it.
Re: (Score:3)
It did adhere to Semantic Versioning before v3.0.
No, it didn't. The numbers did have some meaning before v3.0, but not the semver meanings. Prior to v3, the first digit, the kernel version, was incremented only when there were major changes, as there were from 0 to 1 and 1 to 2. The second digit had special meaning; even values were for "stable" releases and odd values were for "development" releases. This ended when Linus realized that it wasn't getting him the sort of testing he wanted of the development releases, and was also encouraging too-large chan
Why not use commit date as version (Score:5, Funny)
Personally, I think it would be better to use the date as the version "number," though I'm sure that people who have thought about this issue more than I have can come up with reasons that's not a good idea.
One other idea, why not just use the git commit hash? That would really roll off the tongue and be easy to remember. I can see it now:
"Just released, Linux Kernel 634713bc047a87bf8eac9674765ae793478c50d2!"
Re: (Score:2)
Re: (Score:2)
If you guys decide to go with the date, please go with ISO dates. There's nothing more confusing than stupid American dates [imgur.com].
Re: (Score:2)
There are no stupid date formats - just stupid people.
Symbols, and words, phrases, and sentences created with those symbols are neither right or wrong in and of themselves. In a given context (e.g. spoken words, computer file name, database representation, printed document etc) each and every method has its place.
That being said, I do agree, and use myself ISO date/time formats when dealing with data, file names, and other things that I want to conveniently order by date/time. (yyyymmddhhmmss). That
Re: (Score:2)
If a format is stupid, I don't care if it insults someone.
Ex: I find it stupid to use commas to split up thousands in english and I find it stupid to use a comma for decimals in french.
Re: (Score:2)
Like, totally, yeah, depending, on, how, you, use, them.
Some standards are totally clueless though, like commas in numbers. You can't write coordinates or arrays if your numbers have commas in them.
Re: (Score:2)
It can make it a bit easier to read. 3493343873.36 vs 3 493 343 873.36 vs 3,493,343,873.36 for example, the comma seems to give you an easier starting point for reading the following number compared to the blank space. Counting the three commas is easier than counting the three spaces to determine it's a number in the billions.
You shouldn't use them in circumstances where you're writing an array, but you probably also shouldn't use spaces in that circumstance either. You don't need to store the numbers with
Re: (Score:2)
Re: (Score:2)
That's another thing I just never understood. Why it ended up that way is beyond me.
Re: (Score:2)
That's how I do my version numbers. Today would be 20150213. Simple and also has the bonus of giving the exact build date.
Possible answer/solution. (Score:3)
I don't have a problem with the way it's currently done, but i have a possible solution that _might_ keep everybody happy.
based-10 numbered like an array.
You version numbers (minus the first significant digit) all go from 0-9, and once a minor-revision pushes a .9 up, it doesn't goto .10 it then reset back to a 1.0
i.e. so v4.9.0.10 = v4.9.1
Major Version == Major Changes (Score:5, Informative)
If the changes are merely incremental bug-fixes and minor feature additions, stay with minor versioning. Otherwise, you are not versioning; you are branding (viz: Windows 8... which IIRC is version 6.2)
Re: (Score:2, Redundant)
I thought the point of a major version (not necessarily in the Linux kernel, but software generally), was to signal a major change
Look at the choices in the poll itself:
1. I like big versions, and I cannot lie
2. v4.0 'cause I get confused easily
The poll is such a joke that for a moment I thought it was meant for April fools day.
Re:Major Version == Major Changes (Score:5, Funny)
I thought the point of a major version (not necessarily in the Linux kernel, but software generally), was to signal a major change
Look at the choices in the poll itself:
1. I like big versions, and I cannot lie
You other coders can't deny.
When a kernel boots up with an itty bitty place
And a round digit in userspace
You get sprung
Re: (Score:2)
Re: (Score:2)
Lots and lots of minor fixes and changes add up to serious architectural rework. Ground-breaking new features are added when ready - one by one - every few months it seems I read about another major change to the kernel - so after a while you have several such major features added, it's unreasonable to add a major number every time.
So while I agree with your general ideas, it's certainly not that easy in the "release early, release fast" world of open source software, as with the fairly rapid addition of ma
Re: (Score:2)
The Linux kernel V3.20 is very different to 3.0, but it was such a gradual change that there was no big bump where a major number would have been incremented.
For projects that evolve that way it can be helpful to keep version numbers fairly small. It's easier to talk about the 3.x era than the 3.0-3.17 era.
Re: (Score:2)
I like it. You zeroed in on the only possible justification that could possibly hold any water at all. I don't buy it, but it's not crazy reasoning.
Re: (Score:2)
If you assume the regular versioning systems work with the linux kernal, then no, it is not major bump time. This whole thing is a storm in tea cup - if Linus can count much above 20 then why not bump to 4? Although I agree the bump should mark some event.
Re: (Score:2)
If linus has trouble counting above 20, the project is in trouble. If you go with 4.0, what happens when it hits 20.0? You are just putting off the inevitable reckoning. He should, with respect, LEARN TO COUNT.
Re: (Score:2)
As matter of fact bug-fixes that don't break backwards compatibilities usually have their own separate number (the last number in the number version):
MAJOR_VERSION . MINOR_VERSION . BUG_FIXES
So you can update your software safely if you keep the same major and minor versions.
In my project the upper echelon of the company wanted to stress out that this was version two of our product (even though the "second version" does not share any code at all with the first) so we ended up introducing one more number to
Re: (Score:2)
Danger, this organization does not have a level of institutional intelligence sufficient for you to consider a continuance of your working relationship.
Re: (Score:2)
It was not so much a case of micro-management and more a case of "either way is fine by me", if I had insisted on keeping 3 numbers they would let me. We only realized the problems of saying 4 numbers out loud after a while when it was too late to change it.
Re: (Score:2)
+1 to date-based.
Here's what I'd do if I were Linus: Bump to 4.0 now, then the next release go to (year-2010, month), so maybe 5.3. If there are two releases in a month (rare), add a third number to distinguish them.
Get rid of the '3'. There is no '4'. (Score:2)
There's no point to the major version anymore, the only reason it's ever updated on the kernel is to make things more readable.
Agreed.
Having the year as the leading number doesn't imply major feature changes when you increment it, plus it solves the problem of huge minor version numbers.
It actually creates a problem where there is none. Same with the 2015.2 format, which I thought was the better plan before I read this thread.
Say we've got linux 3.20 now. It's easy for developers to think about what's on
OS L (Score:5, Funny)
Just call it OS L and be done with it.
"No it's not OS el you incompetent hag, it's OS fifty!"
Why Linus Forces users to use Google+ (Score:2, Insightful)
It makes me sad. Not about version numbering. Why does Linus force the users to use Google+. It somehow feels very wrong to me.
Re: (Score:2)
It's not like any blog hosting/software would be different. One still have to register to leave a comment - as it always was.
Re:Why Linus Forces users to use Google+ (Score:5, Funny)
It's not like any blog hosting/software would be different. One still have to register to leave a comment - as it always was.
I guess I didn't get that memo.
Re: (Score:2)
It makes me sad. Not about version numbering. Why does Linus force the users to use Google+. It somehow feels very wrong to me.
It is a silly poll to express a completely non-binding opinion. Linus will do whatever he feels like doing in the end.
It isn't like the kernel now has a GOOGLE_ID config item that is validated before it will compile/run.
Re: (Score:2)
On the flip side, I actually *see* Linus' posts on Google+, whereas on Crackbook they'd be buried under the deluge of cat videos... :P
Join the crowd (Score:4, Insightful)
Why not adopt the new standard, jump your major revision number to 10, and then leave it there forever; just like Apple and Microsoft?
Re: (Score:2)
Well, Apple is almost to the point where their current major version "X" has been around the same amount of time as major versions 1-9 combined. Unless they go to version 11 (XI?) they'll be there within 2 years.
Incremental development (Score:4, Insightful)
It is artificial to bump the major version every time when the minor version merely begins to "feel too large".
The development of Linux is mostly incremental. A date code or just a single rolling number might suit the project better.
Re: (Score:2)
imposter! (Score:5, Funny)
What I'd love to see for 4.0 (Score:2)
The main thing I'd like to see for 4.0 is a massive simplification of the kernel, removing features that are no longer used anywhere. There's a lot of duplicated functionality in the kernel - two different ways to report hotplug events, three different ways to report ACPI events, several dozen filesystems, some of which don't actually work or even have userland tools that will compile on modern kernels.
So I'd like to see a winnowing of kernel features, down to a saner, all-known-to-work set.
Also, can we ple
Follow the Ubuntu versioning scheme. (Score:5, Interesting)
Follow the Ubuntu versioning scheme, it's simple... kernel was release in Febuary 2015, then you would call it 15.2
Re: (Score:2)
What happens when the major version gets too big? (Score:2)
Will he just start over again, with a new kernel?
Save the major version bumps for large refactorings.
Linux 10 (Score:2)
Get with the trend guys.
Or just LinuX.
A question that is just as relevant (Score:2)
24 bit color (Score:2)
Linus missed the knuth converge to pi opportunity.
Failing that, a 6 digit hex string is how nature intended it. One can then plot users graphically by version number.
If you ever run past 256 major versions, there's always the alpha channel. :)
We're linking to WHERE? (Score:2)
Re: (Score:2)
New scheme (Score:2)
Obviously, the next verision of Linux needs to be "Linux 11 for Computers" - we need to look more advanced than OS X and Windows 10.
Other variants can be "Linux 2015 Mobile Edition" for phones and tablets, and "Linux Server 2011 (Based on Linux 3.0 technology)" for servers.
major.minor should be feature.bugfix (Score:2)
I would change major when features change, and minor for bug fixes only.
That way you can quickly tell if your kernel has the exact same features than another one, and if you have got the same bug fixes.
Then yes, it would be a good moment to start with 4.0
let 4.0 be the one requiring systemd ... (Score:2)
... so I can stay away from it and know when to change to BSD
Re:Want sexy versions? (Score:5, Funny)
WWII tank name conventions! Linux SuperKernel M4A0
Re: (Score:2)
"But vee had to change ze naming scheme; ze focus gwrooops liked 'Slightly Annoyed Kitten' better."
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
me too.
Re: (Score:2)
Eh, a little bikeshedding makes everyone feel included. I'm all for it.
Re: (Score:2)
Screw that - be a man and use Hexadecimal version numbers... wusses.
(warning: might cause *some* confusion initially, so don't take it seriously, eh?)