funny way of numbering kernel versions

steve_dum at mentorg.com steve_dum at mentorg.com
Wed Nov 17 18:26:13 UTC 2004


In message <20041117071138.GD14919 at redhat.com>you write:
>On Wed, Nov 17, 2004 at 12:00:13AM -0500, seth vidal wrote:
>
> > >  > My guess is that this will quite likely limit an exposure of this
> > >  > kernel to testers.
> > >  
> > > I goofed. Next one goes out as _FC4 instead of _devel
> > > sorry,
> > 
> > 2.6.9-1.650_FC4 will not be higher than 2.6.9-1.667
>
>Damn, you got me. This is the only annoying thing with having
>multiple releases on the same kernel level. They're not
>/exactly/ the same kernel, and as they come different
>parts of the CVS tree, it's perfectly feasable for
>a 2.6.9-1.650 to show up in FC2, FC3, and devel (FC4).
>
>I could do something really ugly, and just bump the
>devel kernels up past the last released FC3 kernel
>each time I do an update, but that is a little sick.

Or, a much more practical solution would be to keep the version number
in a separate file in the CVS tree, and have ALL the branches use HEAD
rather than branching that file.  This way, any kernel released will be
assigned a new unique number without having to try to figure out how
to compare alpha characters in the revision string.

This approach would guarentee uniqueness, but still leaves some slight
confusion about how a 2.6.9-1.667 kernel compares to a 2.6.9-1.668
kernel.  It sounds like even if each release bumped the version number,
the actual patch set applied to the kernel could be vastly different.
But this does solve the problem that a kernel released later than the
one currently installed would be readily installed by rpm.

steve

>
>		Dave
>
>
>




More information about the fedora-test-list mailing list