On Mon, Jan 29, 2024 at 03:43:39PM -0800, Adam Williamson wrote: > 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.
This is the kind of rule that is a prime target for automation. Can we have Fedora Rawhide gating validate that the NEVR doesn't go backwards, and block bad builds from getting into the compose. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
