https://bugzilla.redhat.com/show_bug.cgi?id=1955394 --- Comment #41 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- > And another question is that should the release branch (eg f34) be exactly the same with the rawhide branch? I mean in both the commit and source code. In general, no and no. The Rawhide branch will move ahead of the stable releases, due to at least the following: - Updates that would create breaking changes or otherwise should not go to a stable release (https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases)—so, yes, it is very common to have a newer upstream version in a newer release. - Mass rebuilds for upcoming release branches (this just happened for F35) or other system-wide changes (Python 3.10, for example); these add a changelog message and bump the release. - Changes by provenpackagers—these are supposed to be done with restraint, but are sometimes needed for accepted Change proposals or to apply an urgent fix when the maintainer is not available. Depending on your choices as maintainer, the various branches may also diverge. Some maintainers feel very strongly that the git history should be linear, with stable releases possibly “behind,” but maintaining the ability to fast-forward merge from Rawhide. These maintainers tend to use version conditionals in Rawhide to accommodate older releases. This approach can be convenient, but tends to break down when also maintaining much older versions for EPEL, especially when upstream issues bug fixes to old major versions or packaging practices have changed a lot over time, as they have where Python is involved. Others feel very strongly that stable release branches should not have anything “irrelevant” merged into their history. For example, these maintainers would never merge a changelog about a Fedora 35 mass rebuild into the Fedora 34 release branch as part of a version update. Instead, they would cherry-pick changes and keep each branch as clean as possible. Each branch is allowed to actually “branch”, or have its own history diverging from the others. Using this approach sometimes means being a little more careful about versioning; see https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_you_need_to_change_an_old_branch_without_rebuilding_the_others. Personally, I don’t have strong feelings about other approach. I tend to let my release branches diverge freely rather than using conditional macros in my spec files, and I’ve moved more in this direction over time—as someone who maintains a lot of Python packages and a lot of packages with EPEL branches, it’s proved to make more sense for me. However, I’m not very strict about changelog hygiene, and will still use fast-forward merges where it seems to make sense. There is no policy or community consensus about which approach is “correct.” Maintainers generally choose freely in their own packages depending on their personal philosophies, the realities of their particular packages, and their comfort level with git. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
