On Mon, 2022-11-21 at 09:00 +0000, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > I was looking for a clear answer in the packaging docs to the question whether > package nevr must be always higher in later releases. I recall people saying that > now 'distro-upgrade' is the recommended upgrade method and the requirement of > keeping the upgrade path without downgrades isn't there anymore. (This comes up > in the semiannual discussion about upgrade tests.) > > But I don't see an unambiguous statement in the Packaging Guidelines either way. > https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily > says that Rawhide is partially exempt, which stongly implies that other branches > are _not_ exempt. > > So… has there been any change of the Guidelines on this and where is > the official policy documented? I think the "rule" on this got lost, probably unintentionally, in a rewrite in 2017. If you look at the original version of the versioning guide on the wiki - https://fedoraproject.org/w/index.php?title=Packaging:Versioning&oldid=459693 - it has this "rule" in the preamble: "In Fedora we want to ensure that there is always an upgrade path from Fedora release to Fedora release and from Fedora release to the packages in updates. To do that we need to make sure the packages in the newer Fedora releases have an equal or higher Epoch:Version-Release (EVR) than the ones in older releases. For example, Fedora-13 ships with foo-1.0-1.fc13 and Fedora-14 ships with foo-1.0-2.fc14. This example shows that the Fedora-14 package will properly upgrade the Fedora-13 package." ...and the "Rawhide exception" was in the same block, a couple of paragraphs later: "The one time where we temporarily break the upgrade path is from released Fedora to rawhide. It is allowable to temporarily have a higher EVR in a released Fedora vs rawhide in cases where we need to get a fix out to users of the Fedora releases quickly (for instance, for a security issue) but the fixed package does not currently build in rawhide (for instance, because of a change in a dependent library that requires porting effort). The changes should be checked into Fedora's SCM for rawhide although there is not yet a build and getting a rawhide build that restores the upgrade path should be a priority." That stayed the same through to March 2017. On March 2, the page was rewritten, with the note "Completely rewritten as part of https://pagure.io/packaging-committee/issue/656 ". In that version - https://fedoraproject.org/w/index.php?title=Packaging:Versioning&oldid=487239 - the preamble is rewritten and contains only a very oblique reference to this issue: "To ensure proper ordering between updates to a package within a Fedora release, as well as between Fedora releases". The "Rawhide exception" and the minorbump note were kept (and moved to the bottom of the page), but it seems nobody noticed these were now an exception to and an expediency for a "rule" that was no longer stated. Practically speaking, before we switched to doing distro-sync-by- default in all supported upgrade methods, broken upgrade paths in packages included in default package sets were treated as release blocking bugs, because they resulted in a violation of the release criteria. Since that switch, we no longer treat them as release- blocking, because they don't break the criteria. I do still like to get them cleaned up when possible. I don't know whether FPC still "intends" for the guideline to exist (and just didn't realize it had rewritten it out of existence), though. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ 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
