nirik ran a script that checks for versioning issues in Rawhide today,
and it found several: https://pagure.io/releng/issue/11922#comment-893797
Some of these followed a pattern, so I figured a reminder was in order.
In all these cases, a new version was pushed to Rawhide, then "reverted"
some time later:
golang-github-nats-io-jwt - bumped to 2.4.1 in July, reverted to 1.2.2
in September
golang-google-grpc - bumped to 1.58.0 in September, reverted to 1.48.0
in October; no 1.58.0 build ever landed, but the revert left the
%release much lower than before
python-mizani - bumped to 0.10.0 on September 10, reverted to 0.9.3 on
September 12
python-pywlroots - bumped to 0.16.6 on November 4, reverted to 0.16.4
later the same day
so the reminder is this: you cannot simply "downgrade" RPM package
versions like this. Especially not if the upgraded version ever made it
into a Rawhide compose.
If a Rawhide user has your package installed, and got the upgraded
version, they will be marooned on that build forever unless they
manually run `dnf distro-sync`. A `dnf upgrade` will not downgrade the
package to the build you now consider to be the "current" one.
If you have to downgrade a package that made it to a Rawhide compose,
you must use an epoch. If the package did not have an epoch before, make
it `Epoch: 1`. If it had an epoch already, bump it by 1. People tend not
to like epochs, so *try* not to have to do this. Be really certain
before pushing out version bumps.
If the "upgraded" build never made it into a compose (as is likely the
case for python-pywlroots) you're *probably* okay, but it's still
something to be careful about - for instance you might fall into the
trap golang-google-grpc fell into with the %release tag.
Thanks folks!
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx
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
