Hi, Thanks for writing up the proposal, Alejandro.
Sep 3, 2025 2:00:52 PM Fabio Valentini <decatho...@gmail.com>:
On the other hand, I've frequently seen Go compiler updates introducing new bugs, new lints / vet things that break compiling existing packages. Pushing these compiler updates to stable releases frequently might be more disruptive than we'd like :(
I tend to agree. With more packages adopting go-vendor-tools and enabling GO111MODULE=on, this will become less of a problem because I think these vet checks (such as the printf one that broke a bunch of packages after Go 1.24) are gated on the go version specified in go.mod when modules mode is used, but that doesn't cover every package. Also, for packages that use quic-go, they need manual dependency updates for new Go versions.
Previously, and similar to the COPR repository I mentioned, I considered the option of adding a new package named golang-latest that ships the latest stable version of Go in all the branches, leaving untouched the current release workflow. However, this approach also has its issues, mainly duplication of the specfile and keeping both packages up to date. But it is still an option in case the community doesn't like my idea.
I would personally prefer this approach so packages that start requiring a newer Go version in new upstream releases part-way through a Fedora release cycle can opt-in (including packages like container engines that we really need to keep up to date and security patched). I would be happy to help fix the macros to allow packages to select a different Go version than the default golang package.
But if we were to go ahead with always having the latest version in stable releases, I think testing in Copr with something like mass-prebuild is important to add to this proposal so we don't break package builds in stable releases. I'm not sure that additional testing requirement would achieve the goal of reducing maintenance burden, though.
Best, Maxwell -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
