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
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
