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