Re: Deprecating old Go versions (and the ports that use them)

On 12/5/25 07:47, Adam Weinberger wrote:
> 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.

   If a port has known security issues that are expected to not be fixed 
then it should inform users building+installing by setting FORBIDDEN 
appropriately so they are informed before installing it. Apparently its 
documented that such an entry should also exist for software of high 
risk that is by design and not actually a vulnerability.
   An entry in the vuxml database is appropriate to inform users after 
install that may have the old package on their system that they have a 
vulnerability to consider. Removing a port due to vulnerabilities 
without a vuxml entry may permit users to continue to keep the software 
around and use it without being aware of its issues.
   MOVED entries do not seem to get passed along to pkg on my system to 
tell me that software I am using was removed and why so the software 
gets left around until I manually read through a list of installed 
version comparisons to see that it is orphaned.
   That reminds me that it seems pkg should be informed of MOVED entries 
fro when a package moves from one ports tree directory to another but 
that too doesn't happen. I'd say bumping a version to update such a 
record is not appropriate since a full program removal+reinstall to 
update such metadata leads to unnecessary downtime and system load. Is 
there a current way to have pkg inform users of relevant MOVED data and 
if so, is it quiet by default other than to avoid full reinstalls?

> 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.

   I admit I don't know anything of go related ports but think of this 
problem in general as it happens for other dependencies including but 
not limited to other compilers too. If there comes a time where a never 
version is needed to build software, how do you propose that such a 
version be stated as a correct approach without it being a wrong 
approach? In the case of the go discussion, it sounds like at the very 
least that a comment should be put near a restriction to describe the 
reasoning+limits of the restriction anytime the restriction itself 
cannot fully describe the limit in a precise way.

> If you have questions, concerns, or thoughts, please reach out to 
> [email protected] (or reply here).
> 
> I'll reach out to individual maintainers with this same information.
> 
> 
> -- 
> Adam Weinberger
> [email protected] <mailto:[email protected]>