funny way of numbering kernel versions

[alan]

On Wed, 17 Nov 2004, Dave Jones wrote:

> 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.

Unfortunatly there is no real good way to describe packages that are of 
the same package, but have undergone different development paths.

For example, I produce package ABC and someone else produces package ABC.  
They may build the same or they may not.  They may have revision numbers 
that are similar or they may not.  Some repositories add in added bits to 
indicate who built it, but that tends to wreck havok with sorting and 
determining what the actual version number is.  (Even more fun is with CVS 
that contains multiple branches and the version number is generated from 
the date with cvs tacked on the end.)

Trying to keep track of changes between versions becomes difficult, 
especially if there are multiple options possible within the package.

Hopefully that makes some sort of sense...

-- 
Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25.