Michael J Gruber wrote:
A minor bump (as in <pkgrel>%{?dist}[.<minorbump>]) only
comes into play
if a "lower" branch needs to move forward without creating a version
ahead of a "higher" branch. And (independent of autorelease) you cannot
do that unless you use divergent git branches and cherry-picks in
dist-git, in which case "version" makes sense per branch only anyways.
But Release MUST maintain the upgrade path from one release to the next.
Also, no, you do not necessarily need to allow the branches to diverge. If
you keep your branches fast-forwarded, you can just fast-forward the
"rebuild for libfoo in Fn" commit with the minor bump to all branches, but
build it only in the fn branch where it is relevant. The minor bump ensures
that doing that maintains the correct upgrade path, so you do not have to
push unnecessary rebuilds to releases where it is not relevant.
In a dist-git where you work with release branches
"contained" in
rawhide - and use macros extensively - you automatically have commits
which you merge down but which don't affect all branches, e.g. rebuild
commits for dependencies or mass rebuilds. I'm not saying this is the best
way of doing things (we should do it differently), but it's a common
pattern. So you can have the "f40 mass rebuild" commit in an f39 branch.
And in a world where you have and accept that, you can also push a
"rebuild for libfoo" to rawhide and merge down to f40 if that is what
you need to have f40 versions <= rawhide versions.
Sure, but as I explained above, this only works properly if you do a minor
bump rather than a full bump to Release. Otherwise you have to rebuild
everywhere or you break the upgrade path.
But as others have pointed out, in the light of distrosync and
macro-determined differences etc. we may just as well give up the
illusion that "-5" means the same in different branches, and
consequently lift the sorting policy between different branches.
But that breaks the upgrade path, so it is a no go.
Kevin Kofler