Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

As almost everybody knows, Linux moved from the 2.6.x version to the brand new 3.x version.

I've seen around many comments also about the fact that the versioning number for the kernel was changed (wikipedia as the major source as you can see here :) ).

The point is that, despite many information about changing the versioning scheme on a time-based format I wasn't able to find anywhere information related to the new versioning scheme.

Does anyone know how the new versioning scheme works?

share|improve this question

migrated from stackoverflow.com Oct 11 '11 at 11:31

This question came from our site for professional and enthusiast programmers.

3 Answers 3

The new versioning scheme is pretty much exactly the same as the old 2.6 versioning scheme, except that "3." is used instead of "2.6." In other words, instead of calling the release after 2.6.39 version 2.6.40, we just called it 3.0. The stable updates, instead of 2.6.40.1, 2.6.40.2, etc. are now 3.0.1, 3.0.2, etc. Instead of 2.6.41, we have 3.1. And so on.

Nothing has changed about the development model, merge window, release cycle, etc. The only change is that we have one fewer component to the version number (ie 3.x instead of 2.6.x).

share|improve this answer
    
And what about the last digit in the previous versioning system? example: 2.6.35.7 The last digit (related to bug fixes if I am not mistaken) is dropped? @Roland –  John Black Oct 10 '11 at 21:05
    
No, the last digit was not dropped. We still have 3.0.1 ... 3.0.4 as "bugfix" releases for the 3.0 one. –  Mircea Gherzan Oct 10 '11 at 21:14
    
I see... Since you are so kind last clarification :). Since 2.6 has now becomed 3.0 the minor revision number is no more used for discriminating among stable/development version (e.g. 2.5 development, 2.6 stable)? @Mircea –  John Black Oct 11 '11 at 0:07
1  
Right, but that it not a change with 3.0. There are no more "development" or "unstable" releases of Linux; every release since 2.6.0 has been a "stable" release. –  Roland Oct 11 '11 at 18:30
    
Wow, you are working on the kernel! I hope you find the time to write here a lot :) –  Emanuel Berg Jan 16 '13 at 0:48

Found some information in this article

Mainly:

"The previous versioning scheme for the 2.6.x series emerged around 2005 from the kernel's transition to shorter time-based release cycles. The major and minor version numbers were pinned at 2.6 and the third digit was used to indicate the actual release. With the new model, the major version is pinned at 3 and the second digit will be used to indicate the actual release number and the third digit will be used for stable releases.

"This obviously also opens the merge window for the next kernel, which will be 3.1. The stable team will take the third digit, so 3.0.1 will be the first stable release based on 3.0," Torvalds explained in the release announcement."

share|improve this answer
    
I've seen that article but it does not provide good information about the new scheduling scheme. See the other reply + comments for further discussion –  John Black Oct 10 '11 at 21:05
    
I read it as the 2.6 is removed in favor of 3, the other digits remain the same as before. –  Chad Oct 10 '11 at 21:14

If by "scheduling" you mean how development goes now, it is like this:

3.7 gets released (and the stable crowd starts their line of 3.7.1, 3.7.2, ...) Linux opens the "merge window", around 2 weeks during which he will accept new features (which usually have been cooking elsewehere). When the merge window closes, Linus releases 3.8-rc0 (release candidate #0), after which only bug fixes are supposed to go into the kernel (sometimes a feature which was merged is taken back). Each following week (approximately) Linus releases -rc1, -rc2, ... until he is satisfied that there are no more bugs (typically around -rc6), and 3.8 is born. Then the cycle starts again. While all this goes on, the developer crowd is busy hacking on changes to be proposed for future merge windows (some features have been worked on literally for years before being deemed acceptable for inclusion).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.