On Linux numbering scheme

On Linux numbering scheme

[Artem S. Tashkinov]

 Hello,



 As time passes by, the Linux numbering scheme makes even less sense. Some time ago there was a discussion on LKML about a new numbering scheme but it didn't come to any positive conclusion and then the subject was forgotten entirely. Not meaning to raise a clamour here (and I suppose I represent a large group of Linux users here). I'm willing to suggest a numbering scheme which I hope will answer all known complaints and criticism.



 The scheme is simple. We start either from 3.0.1 [.stable] or from 3.10.0 [.stable].



 The first digit will remain "3" forever, to preserve compatibility with all existing utilities and internal Linux kernel code. So, the concern about older utilities breakage is answered here: both 3.0.1 and 3.10.1 are bigger than any currently released kernel.



 The second number will be either 10 (the current year) or 0 meaning we have reset the numbering altogether. However in my opinion 10 sounds better than 0.



 Now, more about the second and third numbers. The second number is just the current year in the 21 century or the same number minus 10. The third number will be incremented with every new release until the next year hits. So, the real next year we'll have 3.11.1, 3.11.2, 3.11.3, etc.



 Now comes a problem, what if we release kernel 3.10.1 this year and the development of the next one commences also this year? What will be the next release number? I suggest to assign the next release number as the following:



 1) Either regardless the actual year the next kernel gets released (this way the kernel development started in 2010 will yield kernel 3.10.2 even though we hit the next year) or

 2) By the day the kernel gets released, so while in development the kernel version remained 3.10.1-rcX, on the 15th of January, we rename it to 3.11.1.


  Artem

Re: On Linux numbering scheme

[kevin granade]

On Thu, Oct 21, 2010 at 3:02 PM, Artem S. Tashkinov <t.artem@lycos.com> wrote:
>  Hello,
>
>
>
>  As time passes by, the Linux numbering scheme makes even less sense. Some time ago there was a discussion on LKML about a new numbering scheme but it didn't come to any positive conclusion and then the subject was forgotten entirely. Not meaning to raise a clamour here (and I suppose I represent a large group of Linux users here). I'm willing to suggest a numbering scheme which I hope will answer all known complaints and criticism.

What are the criticisms?  I think outlining the goals might be a good idea:
1. Numbering scheme must monotonically increase with each release when
evaluated as a version number, including transitioning from the
current numbering system.
2. Individual elements of the version number should remain relatively small.

>
>
>
>  The scheme is simple. We start either from 3.0.1 [.stable] or from 3.10.0 [.stable].
>
>
>
>  The first digit will remain "3" forever, to preserve compatibility with all existing utilities and internal Linux kernel code. So, the concern about older utilities breakage is answered here: both 3.0.1 and 3.10.1 are bigger than any currently released kernel.
>
>
>
>  The second number will be either 10 (the current year) or 0 meaning we have reset the numbering altogether. However in my opinion 10 sounds better than 0.
>
>
>
>  Now, more about the second and third numbers. The second number is just the current year in the 21 century or the same number minus 10. The third number will be incremented with every new release until the next year hits. So, the real next year we'll have 3.11.1, 3.11.2, 3.11.3, etc.

Any particular reason not to continue the date-oriented format and
have the third number be the numerical representation of the month
rather than an incrementing numbering of the releases?  It would still
be monotonically increasing, which is the only requirement, right?

>
>
>
>  Now comes a problem, what if we release kernel 3.10.1 this year and the development of the next one commences also this year? What will be the next release number? I suggest to assign the next release number as the following:
>
>
>
>  1) Either regardless the actual year the next kernel gets released (this way the kernel development started in 2010 will yield kernel 3.10.2 even though we hit the next year) or
>
>  2) By the day the kernel gets released, so while in development the kernel version remained 3.10.1-rcX, on the 15th of January, we rename it to 3.11.1.

I very much think the first option is superior, the version number
would mark the opening of the merge window.  With the other option it
introduces a discontinuity into the process that seems unnecessary.

>
>
>  Artem
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: On Linux numbering scheme

[Al Viro]

On Thu, Oct 21, 2010 at 07:06:23PM -0500, kevin granade wrote:

> Any particular reason not to continue the date-oriented format and
> have the third number be the numerical representation of the month
> rather than an incrementing numbering of the releases?  It would still
> be monotonically increasing, which is the only requirement, right?

Why do we need to change it, anyway?

Al, fully expecting to be whined at for discouraging potential contributors
and horribly damaging Linux ecosystem by artificially increasing the entry
barrier, or something...

Re: On Linux numbering scheme

[Athanasius]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

On Fri, Oct 22, 2010 at 03:00:06AM +0100, Al Viro wrote:
> On Thu, Oct 21, 2010 at 07:06:23PM -0500, kevin granade wrote:
> 
> > Any particular reason not to continue the date-oriented format and
> > have the third number be the numerical representation of the month
> > rather than an incrementing numbering of the releases?  It would still
> > be monotonically increasing, which is the only requirement, right?
> 
> Why do we need to change it, anyway?

  /agree

  For the most part it's only distribution maintainers that see or care
about the kernel version number anyway.  Anyone else knows what they're
getting into if they compile a kernel themselves, and otherwise is more
likely to say they're using "Linux 10.10" right now ....

  Having said that I had a lovely suggestion in the last round on this
topic which would allow you to know when a kernel was released just from
its version number :).

-- 
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: On Linux numbering scheme

[Artem S. Tashkinov]

 I don't suggest changing it completely per se, I only propose to make
it a bit saner and more comprehensible.

Right now the end user given a kernel release number won't be able to 
say  if his kernel is recent enough or not. The new numbering scheme
makes it  easy to understand when  a particular  kernel was released
and makes it quite obvious to see how old the running kernel is.

What can you say about kernel 2.6.32? Almost nothing.

What can you say about kernel 3.11.3? - it is the third release of
Linux in 2011.

Best wishes,

Artem


----- "Athanasius" <link@miggy.org> wrote:

> On Fri, Oct 22, 2010 at 03:00:06AM +0100, Al Viro wrote:
> > On Thu, Oct 21, 2010 at 07:06:23PM -0500, kevin granade wrote:
> > 
> > > Any particular reason not to continue the date-oriented format
> and
> > > have the third number be the numerical representation of the
> month
> > > rather than an incrementing numbering of the releases?  It would
> still
> > > be monotonically increasing, which is the only requirement,
> right?
> > 
> > Why do we need to change it, anyway?
> 
>   /agree
> 
>   For the most part it's only distribution maintainers that see or
> care
> about the kernel version number anyway.  Anyone else knows what
> they're
> getting into if they compile a kernel themselves, and otherwise is
> more
> likely to say they're using "Linux 10.10" right now ....
> 
>   Having said that I had a lovely suggestion in the last round on
> this
> topic which would allow you to know when a kernel was released just
> from
> its version number :).
> 
> -- 
> - Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
>                   Finger athan(at)fysh.org for PGP key
> 	   "And it's me who is my enemy. Me who beats me up.
> Me who makes the monsters. Me who strips my confidence." Paula Cole -
> ME

Re: On Linux numbering scheme

[Alexey Dobriyan]

On Fri, Oct 22, 2010 at 1:33 PM, Artem S. Tashkinov <t.artem@lycos.com> wrote:
> What can you say about kernel 2.6.32? Almost nothing.
>
> What can you say about kernel 3.11.3? - it is the third release of
> Linux in 2011.

And? What a useless information.

BTW, it should be 3.2011.3, see Y2K.

Re: On Linux numbering scheme

[Artem S. Tashkinov]

----- "Alexey Dobriyan" <adobriyan@gmail.com> wrote:

> On Fri, Oct 22, 2010 at 1:33 PM, Artem S. Tashkinov
> <t.artem@lycos.com> wrote:
> > What can you say about kernel 2.6.32? Almost nothing.
> >
> > What can you say about kernel 3.11.3? - it is the third release of
> > Linux in 2011.
> 
> And? What a useless information.
> 
> BTW, it should be 3.2011.3, see Y2K.

Do you really believe Linux kernel will make it through 2100?

I bet by that time we will have some totally different hardware and
software. Besides none of use will be alive by that time, so I don't
see a problem. Besides, upon reaching 2100, if Linux still exists in
its current form, the first digit could be increased to 4. :)

Best wishes,

Artem

Re: On Linux numbering scheme

[Genes MailLists]

On 10/22/2010 06:41 AM, Alexey Dobriyan wrote:
> On Fri, Oct 22, 2010 at 1:33 PM, Artem S. Tashkinov <t.artem@lycos.com> wrote:
>> What can you say about kernel 2.6.32? Almost nothing.
>>
>> What can you say about kernel 3.11.3? - it is the third release of
>> Linux in 2011.
> 
> And? What a useless information.
> 
> BTW, it should be 3.2011.3, see Y2K.
> --

   If you -really- wanna go that route - may as well be

      20.11.3.18

    century.decade.month.day .. that way we don't have problem until we
hit the year 10,000 ... :-)


  g

Re: On Linux numbering scheme

[kevin granade]

On Fri, Oct 22, 2010 at 8:25 AM, Genes MailLists <lists@sapience.com> wrote:
> On 10/22/2010 06:41 AM, Alexey Dobriyan wrote:
>> On Fri, Oct 22, 2010 at 1:33 PM, Artem S. Tashkinov <t.artem@lycos.com> wrote:
>>> What can you say about kernel 2.6.32? Almost nothing.
>>>
>>> What can you say about kernel 3.11.3? - it is the third release of
>>> Linux in 2011.
>>
>> And? What a useless information.
>>
>> BTW, it should be 3.2011.3, see Y2K.
>> --
>
>   If you -really- wanna go that route - may as well be
>
>      20.11.3.18

I think the reason day was excluded by previous suggestions is that
the current development model doesn't generate a "blessed" version on
anything close to a daily rate.  Even if you wanted to incorporate the
-rcs or -next into this scheme, it seems like it'd be somewhat
problematic since the day field would drop in value during development
e.g.
20.11.3.18 = 2.6.37-rc1
20.11.3.25 = 2.6.37-rc2
20.11.4.2  = 2.6.36-rc3

That having been said, <century>.<year>.<month> would be as valid as
3.<year>.<month>, and might help drive home the point that the version
number is "a point in development" rather than some kind of "indicator
of feature releases".

>
>    century.decade.month.day .. that way we don't have problem until we
> hit the year 10,000 ... :-)

Or until the New Galactic Calendar is introduced... ;)

Silliness aside, what are the deficiencies of the current numbering
that are being addressed here?  The only things I can come up with
are, "major number is getting too big" and "development no longer
follows a major/minor feature based model, so the version numbering
scheme should reflect this".  Are there any other reasons for a
change?

Kevin

>
>
>  g
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: On Linux numbering scheme

[Bill Davidsen]

Athanasius wrote:
> On Fri, Oct 22, 2010 at 03:00:06AM +0100, Al Viro wrote:
>> On Thu, Oct 21, 2010 at 07:06:23PM -0500, kevin granade wrote:
>>
>>> Any particular reason not to continue the date-oriented format and
>>> have the third number be the numerical representation of the month
>>> rather than an incrementing numbering of the releases?  It would still
>>> be monotonically increasing, which is the only requirement, right?
>>
>> Why do we need to change it, anyway?
>
>    /agree
>
>    For the most part it's only distribution maintainers that see or care
> about the kernel version number anyway.  Anyone else knows what they're
> getting into if they compile a kernel themselves, and otherwise is more
> likely to say they're using "Linux 10.10" right now ....
>
>    Having said that I had a lovely suggestion in the last round on this
> topic which would allow you to know when a kernel was released just from
> its version number :).
>
I thought the odd/even numbering used to 2.5.xx was fine, and I think having the 
numbering reflect feature set (as it more or less does now) is better than any 
scheme based on date.

That said, this topic will be decided by the vote of the electorate, from a 
voter pool of one (Linus). Unless he has changed his mind this is all moot anyway.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: On Linux numbering scheme

[Jeremy Fitzhardinge]

 On 10/21/2010 07:00 PM, Al Viro wrote:
> On Thu, Oct 21, 2010 at 07:06:23PM -0500, kevin granade wrote:
>
>> Any particular reason not to continue the date-oriented format and
>> have the third number be the numerical representation of the month
>> rather than an incrementing numbering of the releases?  It would still
>> be monotonically increasing, which is the only requirement, right?
> Why do we need to change it, anyway?
>
> Al, fully expecting to be whined at for discouraging potential contributors
> and horribly damaging Linux ecosystem by artificially increasing the entry
> barrier, or something...

I think it should be blue.

    J

Re: On Linux numbering scheme

[Tejun Heo]

On 10/22/2010 04:00 AM, Al Viro wrote:
> On Thu, Oct 21, 2010 at 07:06:23PM -0500, kevin granade wrote:
> 
>> Any particular reason not to continue the date-oriented format and
>> have the third number be the numerical representation of the month
>> rather than an incrementing numbering of the releases?  It would still
>> be monotonically increasing, which is the only requirement, right?
> 
> Why do we need to change it, anyway?

Agreed.  These days, I use just the last digit, as in kernel 36, in
casual contexts.  It's a number as good as any other.  I don't think
it needs to be changed actively.  If the 2.6. prefix is bothering,
just use the last number and maybe that will become semi-official in
the future, or maybe not.  Doesn't really matter.

-- 
tejun

Re: On Linux numbering scheme

[Artem S. Tashkinov]

----- "Tejun Heo" wrote:

> On 10/22/2010 04:00 AM, Al Viro wrote:
> > On Thu, Oct 21, 2010 at 07:06:23PM -0500, kevin granade wrote:
> > 
> >> Any particular reason not to continue the date-oriented format and
> >> have the third number be the numerical representation of the month
> >> rather than an incrementing numbering of the releases?  It would
> still
> >> be monotonically increasing, which is the only requirement, right?
> > 
> > Why do we need to change it, anyway?
> 
> Agreed.  These days, I use just the last digit, as in kernel 36, in
> casual contexts.  It's a number as good as any other.  I don't think
> it needs to be changed actively.  If the 2.6. prefix is bothering,
> just use the last number and maybe that will become semi-official in
> the future, or maybe not.  Doesn't really matter.
> 
> -- 
> tejun

That's my point. "2.6" prefix is totally meaningless nowadays. I just
want to rejuvenate the numbering scheme and make it easy to understand
and comprehend. What's the difference between .16 and .36? Besides, I
just think these huge numbers look unsightly. Do you know any other
piece of software which has the same huge numbers?

Re: On Linux numbering scheme

[Tejun Heo]

On 10/25/2010 11:45 AM, Artem S. Tashkinov wrote:
> That's my point. "2.6" prefix is totally meaningless nowadays. I just
> want to rejuvenate the numbering scheme and make it easy to understand
> and comprehend. What's the difference between .16 and .36? Besides, I
> just think these huge numbers look unsightly. Do you know any other
> piece of software which has the same huge numbers?

Well, there's no difference between 16 and 36, so what would be the
rationale for changing it?  The only reason is that it's unsightly and
uncommon, but, if you ask me, 36 is _much_ closer to 42 and so is
_much_ better.  The glory days of kernel 42 are coming.  Lo and
behold.

Also, it costs to change numbering scheme.  Think about all the
scripts, distros, poor admins and technical writers (and the dolphins
and fishes).  If 2.6. is too ugly and useless, let's let it wither
away in places it doesn't matter.  No reason to cause disruption
without any real benefit.

Thanks.

-- 
tejun

Re: On Linux numbering scheme

[Bernd Petrovitsch]

On Mon, 2010-10-25 at 05:45 -0400, Artem S. Tashkinov wrote:
[....] 
> That's my point. "2.6" prefix is totally meaningless nowadays. I just

Only if you ignore the first 10(?) years of the Linux kernel.

> want to rejuvenate the numbering scheme and make it easy to understand
> and comprehend. What's the difference between .16 and .36? Besides, I

`diff -urN` will show. SCNR ...
What' the difference between 2010-3 and 2010-11?
Hooray, 8 months.
But what does that really tell us?
Nothing about the released item. And we loose the information if there
were other releases in between.

> just think these huge numbers look unsightly. Do you know any other
> piece of software which has the same huge numbers?

Yes, those that use years (and months) in their release numbering
scheme.
And no, because they release so often new "major" releases that they are
thus inherently unstable and buggy. SCNR ...

It makes absolutely no sense to use any version numbering (or naming) as
such as an indicator for anything - except *within the very same
project* to keep the releases in chronological order - both for humans
and software/scripts/tools/.....
Relying on release numbers for QA (or similar issues) is not a good
idea.

Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at

Re: On Linux numbering scheme

[Nick Bowler]

On 2010-10-25 05:45 -0400, Artem S. Tashkinov wrote:
> Do you know any other piece of software which has the same huge
> numbers?

Yup:

  % less --version
  less 436

  % xterm -version
  XTerm(262)

36 is small fry :)

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: On Linux numbering scheme

[Dick Streefland]

Nick Bowler <nbowler@elliptictech.com> wrote:
|   % less --version
|   less 436
| 
|   % xterm -version
|   XTerm(262)
| 
| 36 is small fry :)

Another interesting versioning scheme:

$ tex --version
TeX (Web2C 7.4.5) 3.14159
...

-- 
Dick

Re: On Linux numbering scheme

[Martin Nybo Andersen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 477 bytes --]

On Tue, 26 Oct 2010, Dick Streefland wrote:

> Nick Bowler <nbowler@elliptictech.com> wrote:
> |   % less --version
> |   less 436
> |
> |   % xterm -version
> |   XTerm(262)
> |
> | 36 is small fry :)
>
> Another interesting versioning scheme:
>
> $ tex --version
> TeX (Web2C 7.4.5) 3.14159
> ...

You are running an old version there ... Even Debian is closer to π ... ;)

$ tex --version
TeX 3.1415926 (TeX Live 2009/Debian)
...

-- 
Regards
Martin

Re: On Linux numbering scheme

[Claudio Scordino]

Hi,

>   As time passes by, the Linux numbering scheme makes even less sense.
>   Some time ago there was a discussion on LKML about a new numbering
>   scheme but it didn't come to any positive conclusion and then the
>   subject was forgotten entirely. Not meaning to raise a clamour here
>   (and I suppose I represent a large group of Linux users here). I'm
>   willing to suggest a numbering scheme which I hope will answer all
>   known complaints and criticism.

This seems to be a periodically recurrent topic on the list.
	
If I've correctly understood all points of view, there are currently two
groups of developers:

1. Those who want to maintain the current numbering scheme, because they
feel comfortable with it, and because they can easily understand the
number of releases between one release and another.

2. Those who prefer having a scheme somehow related to the date, so they
can easily understand when a certain kernel has been released (i.e. how
"old" it is).

Does really exist a numbering scheme that can satisfy both groups of
people ? Probably not.

My only idea would be to maintain the usual numbering scheme, and just
replace the second number (6) with the year of release.

For example:

	2.6.36 would be 2.10.36

	2.6.37 would be 2.11.37

	2.6.38 would be 2.11.38

	and so on...

This way, you put some information about the year of release without
loosing all the benefits of the current scheme.

But this means having two independent incremental numbers, which maybe
is a too insane scheme.

Regards,

	Claudio

Re: On Linux numbering scheme

[Geert Uytterhoeven]

On Thu, Jan 6, 2011 at 09:31, Claudio Scordino <claudio@evidence.eu.com> wrote:
>>   As time passes by, the Linux numbering scheme makes even less sense.
>>   Some time ago there was a discussion on LKML about a new numbering
>>   scheme but it didn't come to any positive conclusion and then the
>>   subject was forgotten entirely. Not meaning to raise a clamour here
>>   (and I suppose I represent a large group of Linux users here). I'm
>>   willing to suggest a numbering scheme which I hope will answer all
>>   known complaints and criticism.
>
> This seems to be a periodically recurrent topic on the list.
>
> If I've correctly understood all points of view, there are currently two
> groups of developers:
>
> 1. Those who want to maintain the current numbering scheme, because they
> feel comfortable with it, and because they can easily understand the
> number of releases between one release and another.
>
> 2. Those who prefer having a scheme somehow related to the date, so they
> can easily understand when a certain kernel has been released (i.e. how
> "old" it is).
>
> Does really exist a numbering scheme that can satisfy both groups of
> people ? Probably not.
>
> My only idea would be to maintain the usual numbering scheme, and just
> replace the second number (6) with the year of release.
>
> For example:
>
>        2.6.36 would be 2.10.36
>
>        2.6.37 would be 2.11.37
>
>        2.6.38 would be 2.11.38
>
>        and so on...
>
> This way, you put some information about the year of release without
> loosing all the benefits of the current scheme.
>
> But this means having two independent incremental numbers, which maybe
> is a too insane scheme.

Then why not drop the leading "2." completely?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: On Linux numbering scheme

[Artem S. Tashkinov]

----- "Geert Uytterhoeven" <geert@linux-m68k.org> wrote:

> On Thu, Jan 6, 2011 at 09:31, Claudio Scordino
> <claudio@evidence.eu.com> wrote:
> >>   As time passes by, the Linux numbering scheme makes even less
> sense.
> >>   Some time ago there was a discussion on LKML about a new
> numbering
> >>   scheme but it didn't come to any positive conclusion and then
> the
> >>   subject was forgotten entirely. Not meaning to raise a clamour
> here
> >>   (and I suppose I represent a large group of Linux users here).
> I'm
> >>   willing to suggest a numbering scheme which I hope will answer
> all
> >>   known complaints and criticism.
> >
> > This seems to be a periodically recurrent topic on the list.
> >
> > If I've correctly understood all points of view, there are currently
> two
> > groups of developers:
> >
> > 1. Those who want to maintain the current numbering scheme, because
> they
> > feel comfortable with it, and because they can easily understand
> the
> > number of releases between one release and another.
> >
> > 2. Those who prefer having a scheme somehow related to the date, so
> they
> > can easily understand when a certain kernel has been released (i.e.
> how
> > "old" it is).
> >
> > Does really exist a numbering scheme that can satisfy both groups
> of
> > people ? Probably not.
> >
> > My only idea would be to maintain the usual numbering scheme, and
> just
> > replace the second number (6) with the year of release.
> >
> > For example:
> >
> >        2.6.36 would be 2.10.36
> >
> >        2.6.37 would be 2.11.37
> >
> >        2.6.38 would be 2.11.38
> >
> >        and so on...
> >
> > This way, you put some information about the year of release
> without
> > loosing all the benefits of the current scheme.
> >
> > But this means having two independent incremental numbers, which
> maybe
> > is a too insane scheme.
> 
> Then why not drop the leading "2." completely?
> 

This will break too many user space scripts/applications which expect
2.x.x.x numbers.

Best wishes,

Artem

Re: On Linux numbering scheme

[Greg KH]

On Sat, Jan 08, 2011 at 09:49:26AM -0500, Artem S. Tashkinov wrote:
> ----- "Geert Uytterhoeven" <geert@linux-m68k.org> wrote:
> 
> > On Thu, Jan 6, 2011 at 09:31, Claudio Scordino
> > <claudio@evidence.eu.com> wrote:
> > >>   As time passes by, the Linux numbering scheme makes even less
> > sense.
> > >>   Some time ago there was a discussion on LKML about a new
> > numbering
> > >>   scheme but it didn't come to any positive conclusion and then
> > the
> > >>   subject was forgotten entirely. Not meaning to raise a clamour
> > here
> > >>   (and I suppose I represent a large group of Linux users here).
> > I'm
> > >>   willing to suggest a numbering scheme which I hope will answer
> > all
> > >>   known complaints and criticism.
> > >
> > > This seems to be a periodically recurrent topic on the list.
> > >
> > > If I've correctly understood all points of view, there are currently
> > two
> > > groups of developers:
> > >
> > > 1. Those who want to maintain the current numbering scheme, because
> > they
> > > feel comfortable with it, and because they can easily understand
> > the
> > > number of releases between one release and another.
> > >
> > > 2. Those who prefer having a scheme somehow related to the date, so
> > they
> > > can easily understand when a certain kernel has been released (i.e.
> > how
> > > "old" it is).
> > >
> > > Does really exist a numbering scheme that can satisfy both groups
> > of
> > > people ? Probably not.
> > >
> > > My only idea would be to maintain the usual numbering scheme, and
> > just
> > > replace the second number (6) with the year of release.
> > >
> > > For example:
> > >
> > >        2.6.36 would be 2.10.36
> > >
> > >        2.6.37 would be 2.11.37
> > >
> > >        2.6.38 would be 2.11.38
> > >
> > >        and so on...
> > >
> > > This way, you put some information about the year of release
> > without
> > > loosing all the benefits of the current scheme.
> > >
> > > But this means having two independent incremental numbers, which
> > maybe
> > > is a too insane scheme.
> > 
> > Then why not drop the leading "2." completely?
> > 
> 
> This will break too many user space scripts/applications which expect
> 2.x.x.x numbers.

What userspace scripts/applications expect numbers like that?  How do
they handle releases like what Linus just did (2.6.37)?

thanks,

greg k-h

Re: On Linux numbering scheme

[Artem S. Tashkinov]

----- "Greg KH" <gregkh@suse.de> wrote:

> On Sat, Jan 08, 2011 at 09:49:26AM -0500, Artem S. Tashkinov wrote:
> > ----- "Geert Uytterhoeven" <geert@linux-m68k.org> wrote:
> > 
> > > On Thu, Jan 6, 2011 at 09:31, Claudio Scordino
> > > <claudio@evidence.eu.com> wrote:
> > > >>   As time passes by, the Linux numbering scheme makes even
> less
> > > sense.
> > > >>   Some time ago there was a discussion on LKML about a new
> > > numbering
> > > >>   scheme but it didn't come to any positive conclusion and
> then
> > > the
> > > >>   subject was forgotten entirely. Not meaning to raise a
> clamour
> > > here
> > > >>   (and I suppose I represent a large group of Linux users
> here).
> > > I'm
> > > >>   willing to suggest a numbering scheme which I hope will
> answer
> > > all
> > > >>   known complaints and criticism.
> > > >
> > > > This seems to be a periodically recurrent topic on the list.
> > > >
> > > > If I've correctly understood all points of view, there are
> currently
> > > two
> > > > groups of developers:
> > > >
> > > > 1. Those who want to maintain the current numbering scheme,
> because
> > > they
> > > > feel comfortable with it, and because they can easily
> understand
> > > the
> > > > number of releases between one release and another.
> > > >
> > > > 2. Those who prefer having a scheme somehow related to the date,
> so
> > > they
> > > > can easily understand when a certain kernel has been released
> (i.e.
> > > how
> > > > "old" it is).
> > > >
> > > > Does really exist a numbering scheme that can satisfy both
> groups
> > > of
> > > > people ? Probably not.
> > > >
> > > > My only idea would be to maintain the usual numbering scheme,
> and
> > > just
> > > > replace the second number (6) with the year of release.
> > > >
> > > > For example:
> > > >
> > > >        2.6.36 would be 2.10.36
> > > >
> > > >        2.6.37 would be 2.11.37
> > > >
> > > >        2.6.38 would be 2.11.38
> > > >
> > > >        and so on...
> > > >
> > > > This way, you put some information about the year of release
> > > without
> > > > loosing all the benefits of the current scheme.
> > > >
> > > > But this means having two independent incremental numbers,
> which
> > > maybe
> > > > is a too insane scheme.
> > > 
> > > Then why not drop the leading "2." completely?
> > > 
> > 
> > This will break too many user space scripts/applications which
> expect
> > 2.x.x.x numbers.
> 
> What userspace scripts/applications expect numbers like that?  How do
> they handle releases like what Linus just did (2.6.37)?
> 

I've just grepped through all the shell scripts installed in Fedora 14 and
I haven't found any `uname -r` references, so it seems like  the base system
is quite safe (I haven't tried to grep through binaries as I have no clue
how to check them).

However sources of VMWare/NVIDIA/VBox/etc. kernel modules have multiples
instances of:

#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 7)
#  error This driver does not support 2.4 kernels older than 2.4.7!
#elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 0)
#  define KERNEL_2_4
#elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 0)
#  error This driver does not support 2.5 kernels!
#elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 7, 0)
#  define KERNEL_2_6
#else
#  error This driver does not support development kernels!
#endif

So, it seems like the only obstacle that stops us from starting a completely
new numbering scheme is proprietary or corporations driven/developed software.

Best wishes,

Artem

Re: On Linux numbering scheme

[Greg KH]

On Sat, Jan 08, 2011 at 11:45:05AM -0500, Artem S. Tashkinov wrote:
> > What userspace scripts/applications expect numbers like that?  How do
> > they handle releases like what Linus just did (2.6.37)?
> > 
> 
> I've just grepped through all the shell scripts installed in Fedora 14 and
> I haven't found any `uname -r` references, so it seems like  the base system
> is quite safe (I haven't tried to grep through binaries as I have no clue
> how to check them).
> 
> However sources of VMWare/NVIDIA/VBox/etc. kernel modules have multiples
> instances of:
> 
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 7)
> #  error This driver does not support 2.4 kernels older than 2.4.7!
> #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 0)
> #  define KERNEL_2_4
> #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 0)
> #  error This driver does not support 2.5 kernels!
> #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 7, 0)
> #  define KERNEL_2_6
> #else
> #  error This driver does not support development kernels!
> #endif
> 
> So, it seems like the only obstacle that stops us from starting a completely
> new numbering scheme is proprietary or corporations driven/developed software.

No, those work just fine as well, you need to look at the KERNEL_VERSION
macro to see that.

And any numbering scheme we come up with, will of course be an
incremental number greater than our current number.

But this topic is on hold now until the next kernel summit when it will
be revisited again.  I narrowly missed changing the numbering scheme
last year, hopefully this year will be different.

thanks,

greg k-h

Re: On Linux numbering scheme

[Mark Hounschell]

On 01/08/2011 11:11 AM, Greg KH wrote:
> On Sat, Jan 08, 2011 at 09:49:26AM -0500, Artem S. Tashkinov wrote:
>> ----- "Geert Uytterhoeven" <geert@linux-m68k.org> wrote:
>>
>>> On Thu, Jan 6, 2011 at 09:31, Claudio Scordino
>>> <claudio@evidence.eu.com> wrote:
>>>>>   As time passes by, the Linux numbering scheme makes even less
>>> sense.
>>>>>   Some time ago there was a discussion on LKML about a new
>>> numbering
>>>>>   scheme but it didn't come to any positive conclusion and then
>>> the
>>>>>   subject was forgotten entirely. Not meaning to raise a clamour
>>> here
>>>>>   (and I suppose I represent a large group of Linux users here).
>>> I'm
>>>>>   willing to suggest a numbering scheme which I hope will answer
>>> all
>>>>>   known complaints and criticism.
>>>>
>>>> This seems to be a periodically recurrent topic on the list.
>>>>
>>>> If I've correctly understood all points of view, there are currently
>>> two
>>>> groups of developers:
>>>>
>>>> 1. Those who want to maintain the current numbering scheme, because
>>> they
>>>> feel comfortable with it, and because they can easily understand
>>> the
>>>> number of releases between one release and another.
>>>>
>>>> 2. Those who prefer having a scheme somehow related to the date, so
>>> they
>>>> can easily understand when a certain kernel has been released (i.e.
>>> how
>>>> "old" it is).
>>>>
>>>> Does really exist a numbering scheme that can satisfy both groups
>>> of
>>>> people ? Probably not.
>>>>
>>>> My only idea would be to maintain the usual numbering scheme, and
>>> just
>>>> replace the second number (6) with the year of release.
>>>>
>>>> For example:
>>>>
>>>>        2.6.36 would be 2.10.36
>>>>
>>>>        2.6.37 would be 2.11.37
>>>>
>>>>        2.6.38 would be 2.11.38
>>>>
>>>>        and so on...
>>>>
>>>> This way, you put some information about the year of release
>>> without
>>>> loosing all the benefits of the current scheme.
>>>>
>>>> But this means having two independent incremental numbers, which
>>> maybe
>>>> is a too insane scheme.
>>>
>>> Then why not drop the leading "2." completely?
>>>
>>
>> This will break too many user space scripts/applications which expect
>> 2.x.x.x numbers.
> 
> What userspace scripts/applications expect numbers like that?  How do
> they handle releases like what Linus just did (2.6.37)?
> 

I've often wondered why that case wouldn't be done as 2.6.37.0 ???

Mark

Re: On Linux numbering scheme

[Arnd Bergmann]

On Saturday 08 January 2011, Artem S. Tashkinov wrote:
> However sources of VMWare/NVIDIA/VBox/etc. kernel modules have multiples
> instances of:
> 
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 4, 7)
> #  error This driver does not support 2.4 kernels older than 2.4.7!
> #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 5, 0)
> #  define KERNEL_2_4
> #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 0)
> #  error This driver does not support 2.5 kernels!
> #elif LINUX_VERSION_CODE < KERNEL_VERSION(2, 7, 0)
> #  define KERNEL_2_6
> #else
> #  error This driver does not support development kernels!
> #endif
> 
> So, it seems like the only obstacle that stops us from starting a completely
> new numbering scheme is proprietary or corporations driven/developed software.

If that was the only obstacle, I'd advocate for using whatever scheme
breaks that code the most ;-)

Seriously, the entire problem is just in perception. The main thing
that's really wrong with the current scheme is that people tend to
see the difference between e.g. 2.6.27 and 2.6.37 as much smaller than
between 2.4.0 and 2.6.0, so there is less incentive to update to the
latest release, while in fact there were three years between the
releases in both cases and we are now a lot more active that we
used to be.

These days, the longterm releases really have the role of the old
even-numbered releases, in the way that distros rely on them for
stability, while the regular releases are used by a relatively small
group of people that are interested in using or developing new
features, like the old odd-numbered development releases.
This analogy ends when you look at the kinds of quality control
we apply to patches going into the longterm or the regular releases, 
compared to old even/odd cycles, but I think it's still useful
to consider it from this viewpoint.

I think it would be good to start the next longterm series with a
new number, since that would send an important message to the
end-users and give us better hopes of having a common longterm
tree for all enterprise and embedded people. It is however still
a lot of time until we need to replace 2.6.32/34/35-longterm, and the
incentive to change a name without any other consequences before
then is pretty low IMHO.

Most importantly, at the 2010 kernel summit it was decided to leave
the numbering alone for now. There certainly wasn't a lack of
ideas for how it should be named (2011/2.7/2.8/3.0/6.37/3.7/...).

	Arnd