Deprecating old Go versions (and the ports that use them)
- Reply: Bakul Shah : "Re: Deprecating old Go versions (and the ports that use them)"
- Reply: Daniel Engberg : "Re: Deprecating old Go versions (and the ports that use them)"
- Reply: Volodymyr Kostyrko : "Re: Deprecating old Go versions (and the ports that use them)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 05 Dec 2025 14:47:54 UTC
Hi everyone,
I just scheduled 3/4 of our Go ports for removal, along with 75 ports. I
want to explain why, and what we should do about it.
TL;DR--75 ports need to try altering USES=go:1.2x -> USES=go, because
likely none of the ports actually need to be deleted!
This is going to cause a scramble up-front here, but it's for our own good.
============================
Why are we deleting Go versions?
============================
Go supports only the latest two minors. All minors older than that have
known bugs and security holes that will never be fixed. Currently we
provide SIX minors, which frankly is irresponsible. I'm going to start
being aggressive about culling old Go versions.
Currently, these 75 ports (plus another 68 for go1.24, and 51 for 1.25) pin
themselves to a Go version with
USES=go:1.23
This *almost always* stems from a misunderstanding:
********************************
When a go.mod says "go 1.23" that means it needs AT LEAST 1.23, *NOT* a
need to pin it to 1.23!
********************************
============================
FACT: 99% of Go ports do not need a version pin!
============================
Go added a major new feature back in 1.21 (IIRC) where new versions of Go
can build software targeting older versions, by restricting its build
features and quirks to emulate those of the target version. In other words,
go1.25 can happily build software written for go1.23.
Additionally, Go added support for building a FUTURE version. In other
words, go1.23 can happily build software written for go1.25! You may see
some builds that say "Downloading go-1.25"---this is the build system doing
the right thing, downloading and utilizing the newer stdlib.
============================
A port I maintain, or a port I care about, is scheduled for deletion. What
should I do?
============================
First and foremost, try a test build with the version specifier removed. In
other words, change:
USES= go:1.23
to
USES=. go
and
USES=. go:1.23,modules
to
USES=. go:modules
If it builds successfully, either commit it, or submit a PR, or at the very
least reach out to the Go team.
If it doesn't work, check for updates upstream! You can try pinning to a
newer version (ex. USES=go:1.24), but be aware that it will still get
deleted when go1.24 gets deleted.
This means that:
**********************************
Any port with a pinned version will last at most 1 year in the ports tree!
**********************************
Go releases two minors a year, so any version-pinned port will last until
two future minors, which is at most a year away.
============================
Can't we turn USES=go:1.23 or USES=go:1.23+ to mean >1.23?
============================
Not really. We really do need a way to pin versions for when a package
simply cannot build with a newer version, but most importantly, the right
approach to version pinning is not to do it in the first place.
If you have questions, concerns, or thoughts, please reach out to
go@FreeBSD.org (or reply here).
I'll reach out to individual maintainers with this same information.
--
Adam Weinberger
adamw@adamw.org