[lkml]   [2008]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Kernel version numbering scheme change
On Thu, 16 Oct 2008, Thorsten Leemhuis wrote:

> On 16.10.2008 02:25, Greg KH wrote:
>> You brought this topic up a few months ago, and passed it off as
>> something we would discuss at the kernel summit. But that never
>> happened, so I figured I'd bring it up again here.
>> So, as someone who constantly is dealing with kernel version numbers all
>> the time with the -stable trees, our current numbering scheme is a pain
>> a times. How about this proposal instead?
>> We number the kernel based on the year, and the numbers of releases we
>> have done this year:
>> For example, the first release in 2009 would be called:
>> 2009.0.0
>> The second:
>> 2009.1.0
>> [...]
> That afaics has one minor downside: You don't know in advance how the next
> kernel is going to be called. Example: the kernel that is currently developed
> could become 2008.4 (the fifth kernel in 2008) if this development cycle in
> the end is one of the quicker ones and gets finished this year. But if
> everything is a bit slower then it might become 2009.0 (the first one in
> 2009).
> Hence people that write a lot of articles about things that happen in linux
> land (like or I do) would be forced to write sentences like "[...]the
> kernel that will become 2008.3 or 2009.0 will have feature foo that works
> like this[...]". That will get really confusing if you read those articles
> half a year later -- especially if that kernel became 2008.3 in the end,
> because foo in 2009.0 might already look quite different again...

pick a name when the merge window opens

either based on when the merge window opens, or when it's expected to be
released (and accept that you may have a 2008.3 released in early 2009, or
a 2009.1 released in december 2008)

David Lang

 \ /
  Last update: 2008-10-16 09:37    [W:0.272 / U:20.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site