Hi everyone!
I would like to discuss a potential change in how we manage Go versions
in Fedora. I mentioned this a few weeks ago here [0]. I will copy and
paste a bit from there. :)
Background: Currently, each Fedora release ships a single Go version
that remains stable throughout that release's lifecycle.
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).
My original idea was/is to maintain identical Go versions across all
active Fedora releases. Ideally, starting with the next Fedora release,
every new stable release would have the latest Go version. For example,
by the time of Fedora 45, Fedora Rawhide, Fedora 45, and Fedora 44 would
have 1.27.
During today's Go SIG meeting [1], we explored different approaches to
the idea. I was going to write a formal proposal, but I guess it's
better to do an RFC first, just in case.
The main issue with my idea is breaking packages in the middle of a
release. Maxwell is rightfully concerned about this. Since we are
migrating to vendoring, the situation will be better than before, but
obviously I am concerned too.
Therefore, the compat approach (hope I understood the idea correctly):
1. Each Fedora release would start with the latest stable Go version in
the main golang package.
2. This version would remain stable throughout the release (no
mid-release major updates to the main package).
3. When the shipped Go version approaches EOL, we would introduce a
compat package (e.g., golang1.27) containing a newer version.
4. These packages would conflict with each other (users install one or
the other)
5. At most two Go versions would be available in a release at any given
time.
I am personally concerned about the complexity of this approach and the
tradeoffs. Go's lifespan is really short, and most upstream projects
move to newer versions constantly. Also, developers tend to go to the
latest version. This approach, on the other hand, helps with the FTBFS
issues.
We also discussed integration with Go's GOTOOLCHAIN=auto feature to use
locally installed RPMs. This would be a longer-term enhancement
requiring upstream changes, but it needs to be explored. I am not sure
how feasible it is nor if it's worth the effort. It would be cool, though :D
Just to be clear, I don't think the current workflow is flawed in any
way; I am just exploring ways to improve it, and if the outcome is to
stay with the current model, that's absolutely fine as far as I see it.
Thanks!
---
[0]
https://lists.fedoraproject.org/archives/list/[email protected]/thread/K7JRMBFOQLZEYVO5LUTZB3JI2GNEOW7X/#ZUTB6UYZDNRE4SU5K2EQW4BOYOHUWLFF
[1]
https://meetbot-raw.fedoraproject.org//meeting-1_matrix_fedoraproject-org/2025-11-03/go-sig-meeting.2025-11-03-19.00.log.txt
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
