When submitting the backported fix for bug #986971 to SLE-10 SP3, I found
that our Git branches for the SLE-10 SP3/SP4 branches for yast2-storage had
diverged from the respective versions in the build service (and thus my
submit request was rejected).
We need to be very careful with that. In this particular case, the tarball
based on the SP4 Git branch had simply been submitted to SP3, too. Both
branches did have the same commits (which was a fortunate coincidence), but
in the wrong order (which was a mess), and the version number of the SP3
build service branch had jumped to the one from the SP4 build service branch.
In Git, however, that version number remained, so when I backported my fix to
that SP3 branch, it was plain wrong: It had gone from 2.13.110 (SLE-10 SP3
GA) via 2.13.110.1, 2.13.110.2 to 2.13.110.3, so of course I numbered my
backport 2.13.110.4.
But in the build service it was already 2.13.113, the next number from the
SLE-10 SP4 Git (and build service) branch. So my numbering would have meant a
package downgrade (which our update tools will not do voluntarily), thus the
submit request was rejected.
The fix for this particular case was to change the version to 2.13.113.1
(skipping 2.13.112 and 2.13.113) in the SP3 Git branch and resubmit the
package to get everything back to sync.
All this mess might have been a very unique accident, but it might also have
happened for other packages, so please watch out for this kind of thing when
working on older versions.
I was lucky (kind of, except for losing the better part of a whole working
day because of that) because (a) I always do a separate commit for version
bump and change log entry, (b) both build service branches contained the same
commits (albeit in a different order, but nevermind) and (c) there was no
version number conflict (I could simply append .1 to the number to fix it).
But in other cases, we might not be so lucky.
So, when you start working on one of those old releases, it might be a good
idea to check the .changes file and the version number in the relevant Git
branch against the ones in the build service.
Kind regards
--
Stefan Hundhammer