kernel versioning

[Arjan van de Ven]

On Fri, 2006-03-10 at 09:44 +0100, Axel Thimm wrote:
> Hi,
> 
> upstream kernels that are release candidates or git sub-rcs etc. are
> versioned in FC/RHEL based on the previous stable kernel release,
> e.g. FC5's 2.6.16-rc5-git9 kernel is released as 2.6.15.
> 
> I generally think that's a good idea (e.g. it *is* 2.6.15 with patches
> towards 2.6.16 and not yet 2.6.16, and the user is not confused that
> he's already running 2.6.16).
> 
> But tons of kernel module projects check on the version of the kernel
> and trigger different code bits. These projects depend on the
> versioning to decide whether some features exist or not.


there is no good solution ;(
because even if it said 2.6.16... that's not enough. the api is still
changing and you'd get patches like "fedora claims 2.6.16 but it's not,
so now we need to back down one level".

So your proposal would trade the issue from one side, for an issue from
the other side. Depending on where in the release cycle the exact cut
is, either can be worse (eg the earlier the cut the more accurate 2.6.15
would be, the later the cut the more accurate 2.6.16)

So all in all... I think this is just an evil that external modules need
to live with as price for being external; it's effectively just the same
price they pay for the non-stable kernel API in general.