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

[el es <el_es_cr@yahoo.co.uk>]

Athanasius <link <at> miggy.org> 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