On Tue, Jan 30, 2024 at 08:08:54AM +0000, Daniel P. Berrangé wrote: > 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. Yeah, seems like it could be a ci test... of course there may be times when it needs to be waived, but we could do that then with full understanding. kevin
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ 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
