On Wed, Nov 23, 2022 at 04:04:59PM -0800, Gordon Messmer wrote: > In the wild, I often see Fedora described as a "semi-rolling" release. As a > policy matter, the distribution promises to be mostly stable, but I find it > increasingly hard to honestly present it as such. > > As a couple of quick examples, I'd point out that in Fedora 35, Blender > updated from 2.93 (an LTS version) to version 3. In Fedora 36, Emacs > updated from version 27 to 28. I've read in the KDE Matrix channel that KDE > will be updated in Fedora 36 to 5.26, even though it has already been > updated from 5.24 -> 5.25 (my reading of the KDE update policy is that > Fedora used to update all releases with every KDE release, but decided to > stop). Firefox and Thunderbird get updates in most releases, even when they > contain API-breaking changes (those really should have an explicit > exception, IMHO.) I could offer more, but my point is simply that examples > of updates in prominent packages isn't hard to find. FWIW, I was sure that we have an explicit exception for Firefox. But https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#exceptions-list doesn't list it. Yeah, I think that the way updates are managed has in practice changed a lot. This is at least partially caused by the slow change in relationship between upstreams and our packaging: the distro is inching ever closer to being a thin delivery mechanism for upstream code and upstream build system and upstream packaging decisions and upstream release cadence. Even a few years ago it was fairly common for the packaging to be a big affair with tweaks to the upstream build system or even a completely custom build, downstream patches, and many modifications to the final layout. There still are packages like this, but less and less. If the upstream is sane, there is no need to deal with any of that. Another aspect that has changed is that many upstreams are better at keeping backwards compatibility. E.g. in Rust and Python ecosystems, semver is now the norm, and in my experience the associated understanding that breaking API is bad is more widespread. So there are less reasons for us not to update. At the same time, software is ever more complicated and moves ever faster, so maintaining multiple versions in parallel is a lot of work. Combining all that (bigger and more complicated packages, saner upstream updates, and our packaging being closer to upstream), just makes it less work for the packager to release the same upstream version in all Fedora releases. Then there's the aspect that for fast-moving software, the latest version may be the only usable version. > That's not necessarily to object to those changes (though I did have to do > some minor fixes after the emacs update, and I grumbled quietly), and I > don't want to disrupt users getting new features if that's what everyone > actually wants. But, it does bother me that the documentation doesn't seem > to reflect reality. I think that the documentation should offer users a > realistic expectation of what they'll get from Fedora. > > Does anyone else feel like the documentation should be updated, or am I > making too much of this? I think the documentation should be updated to follow the changing practice. I'd change the policy to allow packages to update to latest versions if deemed the best option by the maintainers. (Guidance when it is actually the best option would need to be provided too of course.) Zbyszek _______________________________________________ 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
