Fix update-metainfo-version.sh flattening the AppStream release history - #13896
Merged
Conversation
The sed in this script had no line anchor, so it rewrote *every* <release> element in the metainfo to the version and date being built, not just the newest one. Running it against the current file turned both entries into duplicates of 5.2.0-beta19, erasing 5.0.0 and 5.0.0-beta9 from the AppStream history a software centre shows. It survived unnoticed because the only callers run it on a disposable CI checkout for the CI flatpak bundle, and that result is never committed. The moment a release-prep PR ran it, the history would have gone. Now it inserts a new entry at the top of <releases>, keeping the older ones, or refreshes just the date if an entry for that version already exists, so re-running is a no-op. Pre-release versions get type="development" so they are not offered as the newest stable. awk rather than sed: the insert is multi-line and awk behaves the same on GNU and BSD. Also adds a --check mode and a verify-metainfo-release-entry job to the release workflow. A Flathub build installs the metainfo from the pinned tag's checkout, so the entry has to exist *before* the tag is cut - v5.1.0 was tagged without it and advertises 5.0.0 as its newest release. The job is cheap and has no needs, so a stable dispatch missing the entry fails in seconds rather than after the full build matrix, and create-release depends on it so the release cannot get out regardless. Pre-release dispatches skip the requirement. Co-Authored-By: Claude Opus 5 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
The
sedinupdate-metainfo-version.shhad no line anchor, so it applied to every line carrying a<release …>opening tag — rewriting the whole release history to the version being built, not just the newest entry. Running it against the current metainfo:Both entries, identical.
5.0.0and5.0.0-beta9gone from the history a software centre shows.It has been harmless so far only by luck: the two callers (
build-flatpak.yml,build-ui.yml) run it on a disposable CI checkout for the CI flatpak bundle, and that result is never committed. The first release-prep PR to run it would have lost the history for real.The fix
date. Re-running is a no-op.<releases>, older entries untouched.-) gettype="development"so they aren't offered as the newest stable.awkrather thansed: the insert is multi-line, and awk behaves identically on GNU and BSD without the-iportability dance.<releases>element at all.Plus a guard for stable releases
A Flathub build installs the metainfo from the pinned tag's checkout, so the entry has to be committed before the tag is cut. v5.1.0 was tagged without it, which is why the manifest we just re-pinned to it advertises 5.0.0 as its newest release.
New
--checkmode, wired into averify-metainfo-release-entryjob. It has noneeds, so a stable dispatch missing the entry fails in seconds instead of after the full build matrix, andcreate-releasenow depends on it so the release can't get out either way.is_prerelease=truedispatches skip the requirement, so beta flow is unchanged.Verified
Against a copy of the real metainfo: insert, re-run idempotency, stable vs pre-release attr, older entries left alone,
--checkfailing then passing, andxmllintclean after each write.Refs #11800.
🤖 Generated with Claude Code