Description of problem: 1.5 in rawhide/f30 1.7 in f29 - System upgrade to 30 downgrade. Version-Release number of selected component (if applicable): How reproducible: Always Actual results: Downgrades package when upgrading from f29 to f30. Expected results: Should upgrade to latest version.
Note that since 2019-02-19, there's also a branched f30 branch, meaning that both f30 and master shall receive the update. IIRC, monotonicly increasing version throughout the Fedora releases was explicit guarded in the past, not sure why this update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-318c6c9e2b (f28 is still in testing, not pushed: https://bodhi.fedoraproject.org/updates/FEDORA-2019-50194f6eb4) was allowed to become stable in the first place, since it would make such equations not longer hold (misbehaviour of dist.rpmdeplint check?). * * * Anyway, the typical workflow is: 1. start with master branch, which shall always be the tip (per the assumptions that used to get guarded explicitly in the past) 2. backpropagate the changes in master bracnh back to release branches, starting with the latest greatest (f30 now), preferably using "git merge --ff-only", stopping when you think you are back in history enough (generally, ABI must not break in the release branches, so if that's the case, change it in Rawhide only and announce the break on fedora-devel ML) Following the step 2., you cannot get into this undesired state that master (Rawhide) or generally newer release branches (f30 here) carry older version of the package than some older distro releases (f29 and possibly f28 here).
This has been fixed with upload / move to 1.8. Package quality is not good.