Released kernel-2.6.5-7.286.TDC.45 for products
SLES9-SP3-TERADATA
update versioning scheme to 2.6.5-7.286.TDC.$RELEASE
!!! WARNING - the next maintenance update will be a downgrade from the
last one 2.6.5-7.330.TDC !!!
The customer reported that the previous maintenance releases
(2.6.5-7.329.TDC) "clashed" with SLES9SP4 because the release number was
higher than for sles9sp4 kernel.
Quoting from an email from Mark Landis:
"
> We've run against an issue with SLES 9 maintenance kernel versioning. The
> two maintenance kernels that have been delivered to our SLES 9 repo,
>
> kernel-smp-2.6.5-7.329.TDC.x86_64.rpm
> kernel-smp-2.6.5-7.330.TDC.x86_64.rpm
>
> have versions greater than the first SLES 9 SP4 kernel version. The SLES 9
> SP4 kernel has ABI changes which make it incompatible with our current kernel.
> Our internal software groups have used the SLES 9 SP4 kernel version as a key
> to switch between the two ABIs where appropriate. Our current maintenance
> version causes their code to select the wrong ABI compliance path.
>
> In order to make this work well, I'd like to propose a version scheme that
> more closely represents the kernel version, and also protects us from these
> ABI issues:
>
> kernel-smp-2.6.5-7.286.XXX.TDC.x86_64.rpm
>
> Where XXX is some value for each maintenance build. This reflects that
> our SLES 9 kernel is based off of the 286 kernel, and also keeps the version
> less than the first kernel shipped with SLES 9 SP4. I'm open to other
> suggestions that can help us prevent the issue outlined here. Whatever we
> can come up with, we just need to make sure it is greater than the last
> SLES 9 kernel we have released to customers:
>
> kernel-smp-2.6.5-7.286.PTF.426350.15.x86_64.rpm
"
We have decided to go with a slightly different scheme which is
2.6.5-7.286.TDC.XXX
where XXX is CURRENT_RELESE-286 so it is basically a counter so it is
guaranteed to be increasing.
suse-commit: 9038a2875f6c6bd38083d98a9e9905d97451c1ac
