Re: [RFC] Kernel version numbering scheme change
From: el es
Date: Thu Oct 16 2008 - 04:22:00 EST
Greg KH <greg <at> kroah.com> writes:
> You brought this topic up a few months ago, and passed it off as
> something we would discuss at the kernel summit. But that never
> happened, so I figured I'd bring it up again here.
> So, as someone who constantly is dealing with kernel version numbers all
> the time with the -stable trees, our current numbering scheme is a pain
> a times. How about this proposal instead?
> We number the kernel based on the year, and the numbers of releases we
> have done this year:
I strongly disagree about the full year indication in front ;)
and bring up my older idea of
the scheme to be s.yy.ww.tt, that is :
s - series, as it is now (freedom to Linus to declare a whole 'new generation'
;) if he wanted )
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.
- most similar to the scheme used so far,
- informative : the ww and tt numbers are the week numbers of when the actual
release HAPPENED, not when it is predicted.
- easy to put some automation into it (git release HEAD now ) could branch the
current and rename it accordingly (not that I know how to do it, just
- (mod) in case there are more than one release in a week, letters could be
used (e.g. 2.08.44[a..z]) in as many count as needed (2.08.45deadbeef.50sodead
)(or put the git commit indication there ?)
- in case the stable releases go forth into next year or over, the stable team
puts additional .yy.ww instead of their own .tt (like 2.08.45.09.05) (yes I know
it is long)
- the -rc releases go as usual beginning with latest mainline release
(2.08.45-rcX, X being a number as it is now)
- dubbing behavior of silicon manufacturers who print the actual week number of
production onto their chips - imagine looking at a chip and quick glancing at
the kernel version number and _knowing_ it should be OK ;)
My Â0.02 ;)
> Any thoughts?
> Let the bike-shedding begin!
> greg k-h
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/