Re: Kernel version : what about YYYY.MM.[01].x ?

From: el es
Date: Tue Jul 22 2008 - 11:18:32 EST

Athanasius <link <at>> writes:

> 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.

I'd agree up to this point. But you really _do_not_ want to predict 'when the
next stable release will be' 'cause this puts pressure on people, and the
current model works good _because_ there is little pressure... If it stops being
fun, some really valuable people could go somewhere else... guess where ?

> 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.
No, the -rcX _is_ good and worth keeping. And the

> I therefore propose the form YYYY.MM.[sd].x

And this is where I disagree completely. You got rid of the traditional series
designator ('s=2' in my scheme), you've lengthened the year part unnecessarily.
Month is too rough grained, that's why I proposed week as a base.

> So, 2.6.26 would have been 2008.07.s.0
> The first update to it would be 2008.07.s.1
> 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.

It revamps the current scheme too much - I have only 'abused' it, you've got rid
of it completely...

> 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.

That's why I think week based grain is better..

el es

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at