linux-kernel - Re: Kernel version : what about s.yy.ww.tt scheme ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Jul 2008 16:02:44 -0700 (PDT)
From:	david@...g.hm
To:	el es <el_es_cr@...oo.co.uk>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Kernel version : what about s.yy.ww.tt scheme ?

On Thu, 17 Jul 2008, el es wrote:

> Hello,
> inspired by the bikeshed painting contest, I got the following idea :
>
> The scheme to be s.yy.ww.tt, that is :
>
> s - series, as it is now (freedom to Linus to bump it to 3 when BKL is removed
> for example ;) )
>
> yy - two (in a hundred years, three) digits of the year
>
> Now the interesting part begins which is
>
> ww - the number of the week of the release. This will be between 1 and 52 (53)
>
> tt - the number of the week of stable release. As above.
>
> I see it like :
>
> Take a hypotetical new-scheme 2.8.30 release (roughly the current 2.6.26, didn't
> count these weeks). Linus starts to accumulate patches for 2.8.30-rcX as usual,
> and when he is ready to release, puts the release week number instead of 30 -
> let's assume it is a 2.8.40 then, more or less. By the time, the stable team
> produces 2.8.30.[32,34,36,38,40 and so on]. If the weeks leap into the next
> year, stable team puts e.g. 2.8.30.9.01 (yy.ww). This scheme would reflect the
> fast pace of development quite good, and also have the information, when the
> code in question was produced actually. I think the weekly granularity is quite
> good idea anyway.
>
> What do you think ?

it means that you cannot know what version of the kernel you are getting 
ready to release.

today we can talk that we are working on 2.6.27 or 'this feature was 
accepted and will be in 2.6.27' any scheme that uses the date of the 
release means that we can't do this.

I see this as a big problem with a fine-grained date scheme.

if we use the year in a date-based scheme and have a near end-of-year 
release slip into the next year (2008.4 is released in Jan 2009) I don't 
see this as a major problem (the bulk of the work was done in 2008 even if 
the final release hit in 2009) under the current development cycle it's 
not like this will end up with 'version 2009.2 released in 2011' type 
emberrasements.

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