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