Hello,
I happen to maintain some applications in Fedora where I am strongly confident our users would prefer "latest and greatest" over 100 % "stability" of the user interface and/or results.
For some of them, I've been more or less silently breaking the Updates Policy hoping that nothing would break (nothing did so far). For others, I've requested FESCo exceptions for individual updates. I'd like to request a permanent exception to allow upgrading the following tools and apps to latest versions in stable Fedora releases.
For transparency reasons, I've decided to share the list of packages on this mailing list before approaching FESCo. It was 10 days ago:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4UK5JT6V6QFDHLW6Z7RQJCFK6AKHKYQ2/
IMHO users want the latest features to support their latest 3D printers and having an outdated version only makes them reach for an alternate source of PrusaSlicer / Cura.
See also https://pagure.io/fesco/issue/2259 and https://pagure.io/fesco/issue/2525
Black is a code formatter with very strict rules. One of the benefit of using black is the determinism of its output. By running black on code twice, it is guaranteed (well, claimed) to produce no changes. When updating it however, new changes might appear on a codebase that was previously considered "OK".
With each release, there might be several subtle changes in formatting, however I expect users who install black from RPM to prefer the latest version of black over total stability of its output. Who needs 100 % stability can "pin" exact black version in their requirements / pipenv /poetry file and get it form PyPI.
Tox aims to automate and standardize testing in Python. As new standards happen, tox is adapted upstream. It very rarely breaks backwards compatibility. Unlike other Python development tools, it is much more beneficial to have tox installed in the system Python stack and not in a virtual environment. I'd like to always provide the latest and greatest tox to our users = Python developers.
Note that this exception would not apply to the planned entire rewrite (i.e. tox version 4), only to latest tox 3.
"HTTPie is a user-friendly command-line HTTP client for the API era. It comes with JSON support, syntax highlighting, persistent sessions, wget-like downloads, plugins, and more." The command line interface is generally very stable and the upstream developers are very interested in seeing the latest version in stable Fedora releases (and eventually also EPEL, but that is out of scope here).
As OwnCloud serves are updated, users might need the latest version of the client installed to be able to use them. Hence, I'd like to be able to update this package freely.
OTOH I don't actually plan to do that often, because I maintain the package "to scratch my own itch" and I would only do that if the server used by our university requires client updates. However, if co-maintainers appear, this could happen more often.
+1
Such an exception would be applicable to plenty of packages, and I think many packagers do this without any discussion. I wonder if we should somehow relax the policy to remove the requirement of fesco tickets in various trivial cases. Something like this: - if the package is non-critpath, and can be safely updated without breaking other packages or user scripts using the package (either does not expose any API, or the API is always changed in a backwards-compatible way), and the maintainer deems this appropriate, they can push updates to stable branches. - if such a policy is adopted, it should be mentioned in the %description: "This package follows an update policy where the major version updates also happen in stable branches."
With %autospec it's becoming even less work to push a version update to an older branch, even if there are some other differences between branches. For many packages which maintain strict backwards compatibility this will only make maintainer life easier and deliver a better user experience.
Can we get a pointer to the precise fedora packaging rule that we are talking about that would require a formal exception? (My understanding is that plenty of packages rebase versions during a stable/previous fedora release.)
Can we get a pointer
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
Thanks. ISTM the text discourages but does not forbid packagers from routine rebases (that are local & compatible in all the desirable ways @zbyszek listed). It's not clear that the policy is mandating the requesting of formal permission from fesco. If that is (and remains) the intent, it should probably spell this stuff out via terms like SHALL? Do we have any idea how many packages routinely rebase? (cough cough some of mine do)
+1 to the exceptions.
I try to stick to "keep things working as best as possible for my users" for updates for my own packages, which I think is the intention of the Update Policy, even if it doesn't spell it out that way. It sounds like it was tailored to "traditional" stuff like libraries with APIs, ABIs, and sonames, and CLIs that might break user scripts, where breaking things with major updates is very disruptive. Keeping client software working for server software that we don't control doesn't really fall under either of those categories, but it has to be updated nonetheless to keep it working.
Note that I am also +1 explicitly.
After a week: APPROVED (+4, 0, 0)
Metadata Update from @zbyszek: - Issue tagged with: pending announcement
Metadata Update from @churchyard: - Issue tagged with: document it
Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SQ6UOPROYBPINNEH2H4MPQQEVCWORZXD/
Metadata Update from @zbyszek: - Issue untagged with: pending announcement
Metadata Update from @zbyszek: - Issue assigned to zbyszek
https://pagure.io/fesco/fesco-docs/pull-request/56
Done now. The new text should be available after the next rebuild (1h?).
Metadata Update from @zbyszek: - Issue untagged with: document it - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.