Slashdot Mirror
Revamped Linux Kernel Numbering Concluded
kernel_dan writes "Following on the heels of a prior discussion about a kernel numbering scheme, KernelTrap has the conclusion. From summary: "Linus Torvalds decided against trying to add meaning to the odd/even least significant number. Instead, the new plan is to go from the current 2.6.x numbering to a finer-grained 2.6.x.y. Linus will continue to maintain only the 2.6.x releases, and the -rc releases in between. Others will add trivial patches to create the 2.6.x.y releases. Linus cautions that the task of maintaining a 2.6.x.y tree is not going to be enjoyable.'" Torvalds suggested specific guidelines to alleviate burn-out of the .y maintainer and Greg KH volunteered to begin maintainership."
The *.x.y kernels are unstable.
The *.x only kernels are stable.
Won't there be a 28 day cycle for
stability on the *.x only kernel?
How *DO* you write a Linux device driver in C#?
fifth sigma, inc.
And all bets are off if you try compiling more than one *.x.y kernel on the same computer ...
...welcome our new many.version.levels.over.lor.ds.
I'd have preferred r-theta polar coordinates.
/me anxious awaits the release of kernel 3.14.1.59.265.35.897.93238462643383279...
Yeah, I agree, Linus kernel is not good for production use. Give Linus a good thwack on the forehead and he may die. Or he may not. It's unpredictable and unacceptable.
Now back in my day, kernels were only found in nuts.
The preceding post has been brought to you by the Automated Joke Destroyer 5000.
It would be cool if it didn't suck.
I just have finished compiling this 2.6.11.0.0.0.0.1 kernel. Damn 2.6.11.0.0.0.0.2 is out, time to recompile.
Okay, you've got your x.0 release. These are for major releases of the software. 1.0, 2.0, etc.
Then you've got your x.x.0 release. Basically, you subdivide your release schedule according to the major tasks needed to get there. So, for instance, if you're creating a video player, 0.1.0 would be to get something proof-of-concept running some basic video codec. 0.2.0 would be for major GUI additions, 0.3.0 would be for extra codeces, etc. These should adhere to a strict roadmap.
Next, you've got the x.x.x release. So, let's say that you're at the GUI stage above, if you've added the player buttons, you're at 0.1.1 (0.2.0 should be reserved for completion of the GUI stage -- are you writing this down?). A menu means 0.1.2, a status bar, 0.1.3 etc. Once more, this should also adhere strictly to the roadmap.
However, you might run into situations where a bug might creep up, and you want to do an extra release between x.x.x releases. This is where you incorporate the a/b/c etc. releases -- for minor changes that occur between the smallest parts of the roadmap. So, if you had an eject button that wasn't working, and you wanted to fix that before moving onto the menu bar, you release 0.1.1a. Small video glitch that arose because of this? 0.1.1b.
But then there are situations in which, well, if you're like myself and consider CVS use to be a waste of time, you'll need to upload release candidates on the above. Hence, the need for a "_rc" suffix. So, if you're checking to see if the fix you made to the eject button is working, you'll have to upload 0.1.1a_rc. If someone wants to add a small change, you get 0.1.1a_rc2, and so on. You might find it easier to add the initials of the developer just so you know who is doing what. So, a 0.1.1a_rc2_fg might not be out of the question.
(By the way, it's a good time to mention that it's best to have any project you're working on include the year that it was started. Why? Just because. Trust me. With all the projects out there right now anyway, we're starting to have to recycle names. So anyway, we're working on vid2004-0.1.1a_rc2_fg at this point.)
Now, and most developers will agree with me on this, every now and then you're going to get sick of the roadmap and want to deviate from it. Maybe add a feature or something ahead of time, just because you find that more motivating than doing extra testing on some module that's probably going to be obsolete by version 0.3.4a_rc3_fg_rt anyway. For these special instances, a descriptive "_plus" is in order.
If you want to see this versioning system in action, check out the latest release of my own project: dml2xml2004-0.4.12aq_plus_rc3.5_a_mdc_ls.tar.gz.
What? Too confusing you say? Just try it. I've found that all three users of my project have no trouble following this extremely clear numbering system.
Windows XP SP2 = NT 5.1.2600
Funny. Someone HAS to have planned that one.
1) Some people might suggest that it's a good idea to put the md5 sum in the version. I couldn't agree more. In these days of rip-offs and trojans, you can't be too careful. I haven't been doing this with dml2xml2004 just yet, but it should become standard in one of the upcoming 3 1/2 releases.
2) Others might think that based on the way debian does things, you might want to put "stable" or "unstable". With all due respect to the folks at debian, I personally find this overkill.
I'll agree with that.. I've watched a few of the lkml threads and his skill at herding cats in scary...
"Consider how lucky you are that life has been good to you so far. Alternatively, if life hasn't been good to you so far
So you're saying that OpenBSD isn't dead, but that it will probably not procreate after it becomes legal for it to marry a same-sex operating system?
You're not seeing it - once they reach 2.6.x.y.z.z.y the solution to all the kernel's problems will appear.
If you give your nuts a good thwack, you'll find those kernels are equally unstable.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
When you're getting paid a boatload to do it.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
It's because the version number of any credible software product has to asymptotically approach Pi as the product approaches perfection. Since Linux is a project that will terminate alongside our civilization and is still in its very infancy, they just want to leave some headroom.
I don't know - did they ever release that article documenting the thought process?
Yes, it says:
What were we thinking?
Don't fight for your country, if your country does not fight for you.