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 ?
On Thursday 2008-07-17 10:51, 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.
Interesting idea.
>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).
-stable usually overlaps with master. But I don't like version
numbers long as binutils and "2.8.30.9.01" have.
(BTW, IMHO it needs more than just a BKL removal to warrant a jump to 3.x)
Jan Engelhardt <jengelh <at> medozas.de> writes:
> >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.
>
> Interesting idea.
>
Thanks :)
> -stable usually overlaps with master. But I don't like version
> numbers long as binutils and "2.8.30.9.01" have.
Yes, master and stable accumulate the same patches, I know. Only master takes
new code, whereas -stable does not.
This however tells how long did it take to produce the -stable release out of
Linus's release ;) And it does not break the current habits - just abuses them a
bit ;)
And tells you how long the version was around there without another -stable
release too. Just by looking onto the version string, quick, sortable in
meaningful way, all sorts of pluses there ;)
IMO, the kernel is so mature already, and the development is so fast, and the
changes not always so fundamental, that the version in the old sense becomes
irrelevant - it is not the 2.4->2.6 transition days any more ;)
Regards,
Lukasz (btw sorry I forgot to sign myself last time ;)
On Thu, Jul 17, 2008 at 10:38 AM, el es <[email protected]> wrote:
> Jan Engelhardt <jengelh <at> medozas.de> writes:
>
>> >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.
>>
>> Interesting idea.
>>
>
> Thanks :)
>
>> -stable usually overlaps with master. But I don't like version
>> numbers long as binutils and "2.8.30.9.01" have.
>
> Yes, master and stable accumulate the same patches, I know. Only master takes
> new code, whereas -stable does not.
>
> This however tells how long did it take to produce the -stable release out of
> Linus's release ;) And it does not break the current habits - just abuses them a
> bit ;)
> And tells you how long the version was around there without another -stable
> release too. Just by looking onto the version string, quick, sortable in
> meaningful way, all sorts of pluses there ;)
>
> IMO, the kernel is so mature already, and the development is so fast, and the
> changes not always so fundamental, that the version in the old sense becomes
> irrelevant - it is not the 2.4->2.6 transition days any more ;)
>
>
>
> Regards,
> Lukasz (btw sorry I forgot to sign myself last time ;)
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
What about how porsch does it
i.g. 911, 912, 913, 914
--
Justin P. Mattock
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
<david <at> lang.hm> writes:
>
> it means that you cannot know what version of the kernel you are getting
> ready to release.
Yes, but when it is at large, everybody would know at a first glance, when it
was released.
>
> 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.
>
With current scheme you say 'it will be in next stable mainline', not telling
any predictions when will it happen, as the stable number is only an increment,
not bound to anything but the cycle. Which many people do not understand and/or
do not want to. My numbering is not the date of _projected_ release, but the
actual date (week) when the release happened. And then, the actual week when the
stable hit large.
> 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.
Yes, my numbering addresses this issue. It is the actual date of release,
encoded week-wise. Any development that is not expected to be 'stable' happens
in 2.mm.ww-rcX where ww is the _last_ stable mainline, frozen. Then, at first
glance you can tell 'Oh, your tree is 3 months older than mine, please rebase
before I pull it' or 'Oh, I need to rebase my tree 'cause I haven't done that
for 4 months' sort of things. Even the automated tools have it easier to tell
you when you push a tree 'Your tree is soooo out of date. Do you really want to
push your stale code to somebody else ?' or 'That tree you're pulling, was last
rebased on code created last year. You sure you want it ?'. Just hypothetically.
>
> David Lang
>
el es
[the 'what' in the topic is a thinko, but I don't want to spoil the thread]
On Thursday 2008-07-17 16:27, Justin Mattock wrote:
>
>What about how porsch does it
>i.g. 911, 912, 913, 914
What about how Peugeot does it
e.g. 306, 406, 206, 307, 407, 207, 308
In reading this thread I've seen folk come up with some good
suggestions, and some bad ones. I think I can sum things up as follows:
1) Need to clearly designate
a) A fresh stable release
b) Also updates to that stable release, without getting confused
with any development releases.
c) A fresh development release/pre-release of next stable, without
getting confused with current stable releases.
2) The only real objection to the status quo seems to be "the 3rd number
is getting too big". This is highly subjective and not a good enough
reason by itself to change the scheme.
3) It would be nice for stable releases to encode when their initial
version was made. This gives extra information in the version number
without having to do a lookup. The problem with this is you don't know
when the next stable release will actually be. This means you can't
base your development version numbering on that, i.e. no simply
appending -rcX to something as you don't know what the something should
be.
But -rcX is just one way of doing it, all we really need is for it to
be clear if a version is part of development or part of a stable
release.
I therefore propose the form YYYY.MM.[sd].x
So, 2.6.26 would have been 2008.07.s.0
The first update to it would be 2008.07.s.1
The development code would continue now as 2008.07.d.0 and onwards
incrementing the last number as development progresses.
Some might object to the user of [sd] on grounds of easy sorting. In
which case just use 0 for stable and 1 for development. Yes, this means
going back to the odd/even designation we had pre-2.6, but as we also
stick to the relatively short development cycle it really doesn't
matter. Also with the base being YYYY.MM we'll only ever use 0 and 1
anyway.
So, YYYY.MM.[0|1].x gives us:
1) Clear indication of when this stable series started.
2) Clear indication of updates to that stable version.
3) Clear designation of the development versions started after
that stable release.
Note however what I said in my 2nd point. The only *real* objection to
the current scheme is 'big numbers', and that's subjective. I only find
it worth making a proposal due to the reasoning in my 3rd point, i.e. it
IS a good idea to encode *when* a stable release was made in its version
number. This not only allows someone to see how long the current
development cycle has been going (to within +/- 4 weeks), but also
allows a glance at all prior versions to show how quickly development
progresses on average between stable versions.
--
- 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
On Fri, Jul 18, 2008 at 9:12 AM, Jan Engelhardt <[email protected]> wrote:
>
> On Thursday 2008-07-17 16:27, Justin Mattock wrote:
>>
>>What about how porsch does it
>>i.g. 911, 912, 913, 914
>
> What about how Peugeot does it
> e.g. 306, 406, 206, 307, 407, 207, 308
>
Those guys are really good at rally,
whats his name gilles pinichi(or something like that)
--
Justin P. Mattock
On Thu, Jul 17, 2008 at 11:48:37AM +0200, Jan Engelhardt wrote:
>
> On Thursday 2008-07-17 10:51, 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.
>
> Interesting idea.
>
> >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).
>
> -stable usually overlaps with master. But I don't like version
> numbers long as binutils and "2.8.30.9.01" have.
also, causes trouble when stable releases cross a year boundary, or
when there are several ones in a week. The stable release should
only be a counter, not a date.
Willy
Willy Tarreau <w <at> 1wt.eu> writes:
>
> also, causes trouble when stable releases cross a year boundary, or
> when there are several ones in a week. The stable release should
> only be a counter, not a date.
>
> Willy
>
>
If there are more stable releases in a week, you could put a release counter
after a dash, say : 2.08.30.40-[2...X]
If stable continues to be used and leaps over to next year, put another .yy.ww
section : 2.08.30.09.02
OK I know that's long, but easy to expand if needed, just be sure to separate
date pieces with dots and counters with dashes. Or...
maybe use them the other way round - the current scheme uses counters separated
by dots, so maybe the new could do ss.yy-ww-tt[[-yy]-ww][.X]] ? Like
2.08-30-40.2 ? 2.08-30-09-02.2 ? But this seems odd, even to me ;)
el es
On Mon, 21 Jul 2008, el es wrote:
>>
>> also, causes trouble when stable releases cross a year boundary, or
>> when there are several ones in a week. The stable release should
>> only be a counter, not a date.
>>
>> Willy
>>
>>
>
> If there are more stable releases in a week, you could put a release counter
> after a dash, say : 2.08.30.40-[2...X]
>
> If stable continues to be used and leaps over to next year, put another .yy.ww
> section : 2.08.30.09.02
>
> OK I know that's long, but easy to expand if needed, just be sure to separate
> date pieces with dots and counters with dashes. Or...
>
> maybe use them the other way round - the current scheme uses counters separated
> by dots, so maybe the new could do ss.yy-ww-tt[[-yy]-ww][.X]] ? Like
> 2.08-30-40.2 ? 2.08-30-09-02.2 ? But this seems odd, even to me ;)
you are well past the point where the complexity overwelmes the
information you are providing.
does it really matter _exactly_ when a release was made?
David Lang
<david <at> lang.hm> writes:
> you are well past the point where the complexity overwelmes the
> information you are providing.
>
> does it really matter _exactly_ when a release was made?
>
> David Lang
>
It might not really matter, but if you could find a reason for it to be useful,
then why not ?
As I wrote before, the development of the kernel is currently quite fast-paced.
The scale of changes is not that dramatic as it was in the early days, is it ?
Of course things get added, removed and so on. You even get lots of development
trees tested in linux-next on a daily basis. With date-based version number, you
can exactly position your own tree in time related to the current development.
It is more human-readable. The version number as it is, just does not entirely
fit the current model of development IMO - with 2 week merge window and roughly
2 months of stabilization period, the counter becomes sort of uninformative...
But for the releases, the week-based granularity seems to be enough - the
current habit of having a stable by number is actually OK too, since the -stable
team does its job. So, yes, to have a similar version number to what is used
currently, the scheme could be s.yy.ww.[nn || -rcX], s=series (2), yy= year,
ww=week when the tree was released, nn= stable number. What do you think ?