Each major.minor version of libgit2 is incompatible with the next, so each such version update must be handled as incompatible according to our policies. For multiple reasons, a compat package for the previous version is made, which makes for a simpler upgrade.
Most recently, libgit2 was updated to 1.9.0, with a 1.8 compat package created. This was announced for rawhide, albeit as it happened and not with the required week-in-advance notice:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/26NKCO67YSYZ2AJJ76WWEJHLJDJY6Y7R/ https://bodhi.fedoraproject.org/updates/FEDORA-2025-44cb6d8bfe
Because the maintainer did provide the compat package, this wasn't immediately disruptive to rawhide despite the lack of notice.
However, the maintainer then proceeded, without announcement or (AFAICS) receiving an exception, to make the same update to the F41 stable branch:
https://bodhi.fedoraproject.org/updates/FEDORA-2025-049d1bd21f
And while again a compat package was provided, and (at least some) dependent packages were rebuilt for the new version, this was disruptive to the stable branch, at least in part. Specifically, it broke the f41-flatpak-app-build buildroot for all rpmautospec'ed packages by causing a mismatch between python-pygit2 (inherited from the aforementioned update and dependent on 1.9, as no flatpaks use it at runtime) and libgit2 (1.8 from f41-flatpak-app, as this is rebuilt and included by a few flatpaks).
While I have since fixed things on the flatpak side to get builds working again, this should not have happened as it did according to policy. As such, FESCo should:
Perhaps we should have a devel list/discussion thread on this to get thoughts on it before we make any adjustments/clarifications on the policy?
AFAICS, no discussion on devel list was started, so I'll reply here.
clarify whether the week-in-advance notification requirement applies even when providing a compat package
I don't think so. The notification requirement is a mechanism to coordinate with other maintainers. If a compat package is provided, then no coordination should be necessary. Hence the notice or delay are not required.
clarify whether and how advance notification is also required for incompatible updates to stable branches which receive or fall under an exception
In general, we don't want to have incompatible updates. But in this case, the update was intended to be compatible, AFAIU. (The message on fedora-devel talks about "seamless upgrades".)
I think this was a case of a bug, where the update that was intended to preserve compatibility actually broke something. Can you link to the fixes that needed to be done?
then no coordination should be necessary.
IIUC this is not true. Package maintainers would likely need to adapt their packages if they'd want to continue building against the "current" version instead of the "new" one, otherwise the next build (for whatever reason) would switch out the libtgit2 library that is linked against.
The following questions were asked:
clarify whether the week-in-advance notification requirement applies even when providing a compat package clarify whether and how advance notification is also required for incompatible updates to stable branches which receive or fall under an exception require an explicit exception for any future stable branch updates due to the potential for buildroot breakage interact with the maintainer in question to assure that future updates are done in accordance with policy
Proposal: Changes to packaging that maintain compatibility can happen at any time, though it is recommended to avoid bigger changes in stable releases. Advance notification is not required when no changes or rebuilds in dependent packages are necessary. When considering compatibility, maintainers must take all into account all the ways that packages are used, i.e. not just rpm builds, but also ostree and flatpaks deployments.
Metadata Update from @humaton: - Issue tagged with: meeting
Approved on todays meeting (5,0,0)
Metadata Update from @humaton: - Issue tagged with: pending announcement
Metadata Update from @humaton: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Note that the proposal that was approved here would not cover the libgit2 updates that were the topic of this ticket (since, for example, dependent packages would have needed spec file adaptations to keep building against the same version of libgit2 and not be silently moved to the new one the next time they would be built).
Log in to comment on this ticket.