Kernel package version rules

[Andy Whitcroft]

On Mon, Jun 29, 2009 at 04:40:02PM +0200, Stefan Bader wrote:
> Andy and myself got into thinking about that one today and both think we saw 
> some definitions but fail to remember any wiki page.
> 
> The problem is, how do we change package versions when we move from one 
> upstream kernel to another (here 2.6.30 to 2.6.31).
> For Intrepid (2.6.26 to 2.6.27) the ABI and the upload number got reset, so 
> 2.6.26-5.17 became 2.6.27-1.1. For the Karmic kernel, we reset the ABI number 
> but did not reset the upload number, which is technically not wrong but 
> inconsistent with the past. Probably (if nobody remembers the place) we need to 
> write down how we think this should be handled, so the next guy to face the 
> problem can read about it somewhere.
> The LBM package number we reset to -1.1 as it has the kernel version number as 
> a part of the package name and thus is a completely new package. But for kernel 
> and meta are just going with the way it is now, as it is not bad enough to make 
> it necessary to redo the whole thing.

The key figure here is the upload number.  The basic rule for this is
that is incremented for each and every upload.  However there seem to be
two different interpretations of this rule.  First it can be interpreted
as the upload number for this version of the upstream contents, or it
can be the upload number for this source package in this series.  These
lead to different transitions when we move to a new kernel version
during the development cycle.  Either is valid in terms of Debian
version numbers.

If we treat the upload number as the per upstream content then we end up
with:

	2.6.30-10.12 -> 2.6.31-1.1

if it is an upload number for the package in this series then we end up
with:

	2.6.30-10.12 -> 2.6.31-1.13

Rather in obviously the linux-backports-modules-* version number
actually is the same in either scheme, as the package contains the
base version in its name and therefore is an entirly new package in the
series:

	2.6.31-10.12 -> 2.6.31-1.1

According the powers that be, the .N extension is non-standard and
therefore there is no standard for it.  Either seems fine and works
as expected from a comparisons point of view.  Personally I am more
comfortable thinking of it a per package per series upload number.

As Colin indicates we need a nice clear example document when we have a
decision.

Comments?

-apw