Messages in this thread | | | From | el es <> | Subject | Re: Kernel version : what about YYYY.MM.[01].x ? | Date | Tue, 22 Jul 2008 15:18:05 +0000 (UTC) |
| |
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
| |