Hey Alejandro Saez Morollon,
My concern is different Go versions with diff Fedora versions, it'll be
great in a sense where one Go version is there in each Fx versions, this
makes us little worry when it comes to check the security patches review.
Thanks and regards,
Aditi
On 9/3/25 6:21 PM, Alejandro Saez Morollon wrote:
Hi everyone, I'm contemplating a change to how we handle the Go
releases in Fedora and would like community feedback before moving
forward with a formal proposal. Currently, each Fedora release ships
with a different Go version. For example,
Hi everyone, I'm contemplating a change to how we handle the Go
releases in Fedora and would like community feedback before moving
forward with a formal proposal. Currently, each Fedora release ships
with a different Go version. For example, right now:
* Fedora 41: Go 1.23 (upgraded to 1.24, see point 1 in the next list)
* Fedora 42: Go 1.24
* Fedora 43: Go 1.25
This creates several problems:
1. Both Go and Fedora releases happen every six months, but they are
a little off; almost end-of-life Fedora releases will have
end-of-life Go versions for around 2 months. To avoid this
scenario, we have to ask for an exception to upgrade Go in those
versions.
2. Package maintainers must support multiple Go versions
simultaneously across different Fedora releases, increasing
testing complexity and bug surface area. Go is superb at
maintaining retrocompatibility, but upstream projects tend to
enforce the latest Go version for different reasons.
3. Go developers tend to use the latest version available as soon as
possible, but this latest version is only available in the latest
Fedora stable release. This has been solved with a COPR
repository, but discoverability might be a problem (it's always
easier to find packages from the repositories).
These issues are not huge concerns, but there is always margin for
improvement.
The idea I'm considering: maintain identical Go versions across all
active Fedora releases. Ideally, starting with the next Fedora
release, every new stable release will have the latest Go version. For
example, by the time of Fedora 45; Fedora Rawhide, Fedora 45, and
Fedora 44 would have 1.27. I would rather not apply this to the
current stable releases to avoid unnecessary mass rebuilds and issues.
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. This idea differs from typical Fedora practices.
However, I think it is viable and will bring several benefits:
* All users get security fixes as soon as possible.
* Reduced maintenance overhead (hopefully).
* Consistent development experience across Fedora versions.
* Better alignment with Go's rapid upstream development.
I would love some feedback before making the official proposal and see
if this is something people would like to have or what issues I might
not be considering.
Thanks!
--
_______________________________________________
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
