V Thu, Nov 24, 2022 at 02:40:09PM +0100, Miroslav Suchý napsal(a):
> > > Does anyone else feel like the documentation should be updated, or
> > > am I making too much of this?
>
> +1 to update documentation. Or even better, document which packages has the
> exception. And later ask QE to create tool which will warn if packages
> outside of this list bump up version.
>
Checking for a version bump does not make sense unless you want to force
maintainers to backport each fix. (Nonpaid maintainers won't do it.)
Many upstreams release bug-fix only versions. It's easier for everyone to take
that new version and place it into stable Fedora than applying the difference
as a patch or cherry-picking various commits from an upstream version
controll sysmte (if there is some). Example is a Perl bump from 5.34.0 to
5.34.1. Also many times you cannot distinguish a bug-fix update from
a breaking change by looking at the version number. Example from perl-YAML
changelog:
1.30 Mon 27 Jan 2020 11:09:46 PM CET
- Breaking Change: Set $YAML::LoadBlessed default to false to make it more
secure
1.29 Sat 11 May 2019 10:26:54 AM CEST
- Fix regex for alias to match the one for anchors (PR#214 TINITA)
1.28 Sun 28 Apr 2019 11:46:21 AM CEST
- Security fix: only enable loading globs when $LoadCode is set (PR#213
TINITA)
It's not only about bug fixes. In the past I was strict in not adding new
version to stable Fedoras. But I was smashed by users and packagers requesting
rebases there. Either because of new features or just only because of the
version numbers because a third-party code checks for a minimal version.
So I ended up actively rebasing packages until a breaking change. I found it
less error prone to evaluate each update as it comes, than keep everything
boilig in Rawhide and than evaluate a lump of interdependent packages once
in a long time. Especially if the interdependencies are not obvious.
Based on these observations I'm against placing a machine blindly rejecting
version bumps.
That does not mean I encourage maintainers to blindly rabase in stable
Fedoras. If they don't feel confident, then they should not do the rebase.
However, to increase the confidence and quality of Fedora updates, I'd rather
see enforcing fedora-ci tests in Bodhi. They already checks changes in RPM
dependencies, changes in shared library ABI, breaking upgrade path etc. An
example <https://bodhi.fedoraproject.org/updates/FEDORA-2022-525152a5b5>. It's
really pitty we do not have these tests globally enabled.
People do mistakes, but it does not mean we should stop updating
a distribution because of that.
-- Petr
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
