pre-release kernel release tag

[Jarod Wilson]

Axel Thimm wrote:
> On Thu, Aug 09, 2007 at 02:21:47PM -0700, Roland McGrath wrote:
>>> On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote:
>>>> I propose we change the release format for snapshot kernels.
>>>> Now we get e.g.:
>>>>
>>>> kernel-2.6.23-0.89.rc2.git2.fc8
>>>>
>>>> and I suggest instead:
>>>>
>>>> kernel-2.6.23-0.rc2.git2.89.fc8
>>>>
>>>> That is, put the spec file version number last, not first.  This way, when
>>>> we forget to reset fedora_cvs_origin after a rebase, we don't have to wait
>>>> for the next kernel version to do it, just the next gitN.
>>>>
>>>> We can't make this change until 2.6.23 sails, since for rpm version
>>>> comparison rc* is < any [0-9].
>>> Please don't do this. The kernel package is finally compliant with the
>>> Fedora Packaging Guidelines and this change would break it again.
>>>
>>> The reason we prefix with the 0.# is to prevent versioning comparison
>>> madness.
>> What?  I didn't propose removing the 0. prefix.  What is the problem?
> 
> Look closer, there's a `#´ in Tom's reply, which is what you want to
> move away. Actually the 0. prefix is not neccessary it is a leftover
> from 3rd party techniques to indicate vendor hierarchies, but it's
> difficult to knock out people's head.

It has nothing to do with any 3rd-party techniques in the case. The 
'0.#' instead of just '#' is so that we can rebase the release number to 
1 on each new major kernel version, so the first released 2.6.23 kernel 
for fc8 will be 2.6.23-1.fc8. At least, that was my intention when I 
wrote this stuff up, and its how we've used it thus far.

Of course, my initial thought had been it'd be nice to not even have the 
'.#' portion in there, since you get reasonably decent rpm ordering with 
just 0.rcX.gitY.fc8, but then if we end up doing a rebuild of the same 
git snap, you have to worry about it, but we don't want to have to muck 
around with that manually. That being the case, putting it after the 
leading 0 for git snaps, automatically incremented over the period 
leading up to the next kernel release, in line with the packaging 
guidelines, made the most sense.

-- 
Jarod Wilson
jwilson at redhat.com