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

el es
2008-07-22T15:18:31Z

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