[opensuse-kernel] KOTD release numbering
Hi, (sorry for the long mail, jump to "== Examples ==" below for the important part) I'm thinking about changing the versioning of KOTD packages (http://ftp.suse.com/pub/projects/kernel/kotd/) as the current scheme is a bit of mess. I'd like to 1) make the release string shorter, 2) make the release string sort with official distro kernels nicely, so that with some luck, an older kotd will be replaced by a newer update kernel and vice versa. I'm thinking about the following: drop the branch name and timestamp from the release string (same information is in rpm -qi output, no need to duplicate it here). Instead of the timestamp, use the number of commits (see below) so that the release string increases. To get proper ordering with official kernels, prepend the release string of the last official kernel. More precisely: last update kernel: $version-$release current kotd: $version2-??? if $version == $version2 $release2 = $release.$ncommits.$hash else $release2 = 0.0.0.$hash remember "$version2-0.0" as a fake update kernel and count from there next time endif $ncommits would be the number of commits to the kernel repository since the last update, $hash would be the commit id (same as today). == Examples == The current SLE11_BRANCH kotd would be named kernel-default-2.6.27.25-0.0.22.8dd1bfd.x86_64.rpm because the last released update was 2.6.27.23 and Greg updated to 2.6.27.25 22 commits ago. The next update (if the version stays at .25) will be 2.6.27.25-0.1, i.e. correctly newer than the kotd. The SL110_BRANCH kotd would be named kernel-default-2.6.25.20-0.4.23.4d35a02.x86_64.rpm because the last released update was 2.6.25.20-0.4, 23 commits ago. The next update will be 2.6.25.20-0.5 at least, again newer than the kotd. Maybe the commit id should be prefixed with a "g", just like git-describe does, to make it clear what it is. Does this make sense to everyone? Does anyone depend on the current numbering scheme? Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wednesday, 24 June 2009 12:30:43 Michal Marek wrote:
Does this make sense to everyone?
This sounds useful except that the "0.0." prefix in the release is a mess again. If version/release numbering scheme in the build service for normal packages is $version-$srcrel.$build, then wouldn't it be possible to set $srcrel to the number of commits since $version, and $build to the build number for all kernels? KOTDs could still use part of the commit ID as a suffix, e.g., kernel-default-2.6.25.20-23.4.4d35a02.x86_64.rpm kernel-default-2.6.25.20-23.4.x86_64.rpm The only problem I see here is that if the KOTD 2.6.25.20-23.4.4d35a02 gets released as 2.6.25.20-23.4, the KOTD would have higher priority than the release. Given that both must be based on the same sources (because the "23" counts from "2.6.25.20"), that doesn't seem so bad though. In another project, I'm using "git describe --tags" for generating the package version and release number. In the kernel case something a little more complicated is needed obviously, but we could still use tags to remember the baseline that the first number in the release number counts from.
Does anyone depend on the current numbering scheme?
Well, we can't really change the numbering scheme for released products, so for those, we'd still end up with ordering issues. Thanks, Andreas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Andreas Gruenbacher napsal(a):
On Wednesday, 24 June 2009 12:30:43 Michal Marek wrote:
Does this make sense to everyone?
This sounds useful except that the "0.0." prefix in the release is a mess again. If version/release numbering scheme in the build service for normal packages is $version-$srcrel.$build, then wouldn't it be possible to set
BTW, for updates / service packs, $srcrel itself can be two or more numbers. So actually the 0.0. above could also be 0. or 0.0.0. or whichever number of branch points the last official package had.
$srcrel to the number of commits since $version, and $build to the build number for all kernels? KOTDs could still use part of the commit ID as a suffix, e.g.,
kernel-default-2.6.25.20-23.4.4d35a02.x86_64.rpm kernel-default-2.6.25.20-23.4.x86_64.rpm
This would be the ideal scheme, however, I'd like not to change the scheme for the distribution itself, I just want to change the kotd to play better with the distro numbering scheme. As you said, to change the scheme for released products is a no-go, and I guess I don't have enough motivation / energy to convince the build service people that we really need to change it for factory... Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wednesday, 24 June 2009 13:19:16 Michal Marek wrote:
Andreas Gruenbacher napsal(a):
On Wednesday, 24 June 2009 12:30:43 Michal Marek wrote:
Does this make sense to everyone?
This sounds useful except that the "0.0." prefix in the release is a mess again. If version/release numbering scheme in the build service for normal packages is $version-$srcrel.$build, then wouldn't it be possible to set
BTW, for updates / service packs, $srcrel itself can be two or more numbers. So actually the 0.0. above could also be 0. or 0.0.0. or whichever number of branch points the last official package had.
Really, still? What a nightmare.
$srcrel to the number of commits since $version, and $build to the build number for all kernels? KOTDs could still use part of the commit ID as a suffix, e.g.,
kernel-default-2.6.25.20-23.4.4d35a02.x86_64.rpm kernel-default-2.6.25.20-23.4.x86_64.rpm
This would be the ideal scheme, however, I'd like not to change the scheme for the distribution itself, I just want to change the kotd to play better with the distro numbering scheme. As you said, to change the scheme for released products is a no-go, and I guess I don't have enough motivation / energy to convince the build service people that we really need to change it for factory...
I don't see why we shouldn't be able to change this in Factory if it improves things. Thanks, Andreas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Michal Marek napsal(a):
I'm thinking about changing the versioning of KOTD packages (http://ftp.suse.com/pub/projects/kernel/kotd/) as the current scheme is a bit of mess. I'd like to 1) make the release string shorter, 2) make the release string sort with official distro kernels nicely, so that with some luck, an older kotd will be replaced by a newer update kernel and vice versa.
FYI, something like this is implemented now. E.g. on master there is: kernel-desktop-2.6.31-8.99.10.050bdf9.x86_64.rpm (the latest factory kernel is kernel-desktop-2.6.31-8.2.x86_64.rpm, 10 commits old. The ugly .99 is a hack to override the rebuild counter). In SLE11_BRANCH, there is: kernel-default-2.6.27.34-0.0.0.12.5a3f608.x86_64.rpm (the latest update kernel was 2.6.27.29, 12 commits ago the kotd was updated to 2.6.27.34). And so on. Note that there are still some packages built with the old numbering. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Michal Marek Wrote:
Michal Marek napsal(a): FYI, something like this is implemented now. E.g. on master there is: kernel-desktop-2.6.31-8.99.10.050bdf9.x86_64.rpm (the latest factory kernel is kernel-desktop-2.6.31-8.2.x86_64.rpm, 10 commits old. The ugly .99 is a hack to override the rebuild counter).
Can you explain a little bit more on "10 commits old". Does it mean the latest factory kernel is 10 commits older then the latest git kernel-source ? Thanks. -- Coly Li SuSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (3)
-
Andreas Gruenbacher -
Coly Li -
Michal Marek