Created attachment 273401 [details] Switch default Go version to 1.26 With Go 1.27 expected later this month, I think we're past due switching the default to 1.26.
Thanks for this, des. I completely lost track of time and missed that month 2+6 had been approaching for some time now. Personally I'd like to see us switch to 1.27 after a few months if everything looks as good as it did for 1.26. I know it's speculative at this point, but do you have thoughts on an upgrade cadence?
Some failures logs: https://pkg-status.freebsd.org/gohan06/data/150amd64-default-foo/2026-08-06_19h31m32s/logs/errors/tinygo-0.19.0_41.log https://pkg-status.freebsd.org/gohan06/data/150amd64-default-foo/2026-08-06_19h31m32s/logs/errors/ollama-0.32.5.log https://pkg-status.freebsd.org/gohan06/data/150amd64-default-foo/2026-08-06_19h31m32s/logs/errors/nncp-8.13.0_12.log
(In reply to Antoine Brodin from comment #2) Are you sure the misc/ollama failure is a regression? The port itself is already pinned at Go 1.27 and the failure occurred in glslc, which is a C++ program (part of graphics/shaderc).
devel/tinygo is five years out of date, we should just mark it BROKEN.
The net/nncp failure is preexisting.
(In reply to Dag-Erling Smørgrav from comment #3) > The port itself is already pinned at Go 1.27 Correction: the port itself is already pinned at Go 1.26.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=35a3e5e5137ed6df3659136c98e4f6bc1c3942b2 commit 35a3e5e5137ed6df3659136c98e4f6bc1c3942b2 Author: Adam Weinberger <adamw@FreeBSD.org> AuthorDate: 2026-08-08 13:27:42 +0000 Commit: Adam Weinberger <adamw@FreeBSD.org> CommitDate: 2026-08-08 13:27:42 +0000 devel/tinygo: Restrict to Go 1.25 and mark BROKEN This port has not been updated in years, and the current port version is incompatible with Go 1.26+. Go 1.26 will become the minimum supported Go version very soon. Unless someone adopts this port (the fact that it's so stale suggests that interest is probably quite low) this port should exit the stage when Go 1.25 does. PR: 297237 devel/tinygo/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
(In reply to commit-hook from comment #7) I didn’t set an EXPIRATION_DATE. I assume we should set it to whatever expiration date devel/go125 gets, which we should probably do ASAP. des, is a month enough of a window? That’ll give us a couple weeks of an unsupported Go version in the tree, but it’s better than the year+ from the last time around.
misc/ollama is yuriware and already broken: https://portsfallout.com/fallout?port=misc%2Follama%24 net/nncp is already broken, but the breakage is caused by go.mk: https://portsfallout.com/fallout?port=misc%2Follama%24 we set GO_CFLAGS as follows: GO_CFLAGS="-buildmode=exe -v -trimpath -ldflags '-s ' -buildvcs=false -mod=vendor" when the port's build script passes this to `go build` it gets expandes as follows: ... "-ldflags" "'-s" "'" ...
Marking devel/tinygo BROKEN is incorrect since it builds fine with 1.25. Pinning it to 1.25 should suffice for now. We can mark it BROKEN if it hasn't been updated by the time we remove 1.25.
(In reply to Dag-Erling Smørgrav from comment #10) Good point, I jumped the gun on that one.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=932f5bf3a0b426ff4b3a6d02587f4e352993a157 commit 932f5bf3a0b426ff4b3a6d02587f4e352993a157 Author: Adam Weinberger <adamw@FreeBSD.org> AuthorDate: 2026-08-08 19:58:25 +0000 Commit: Adam Weinberger <adamw@FreeBSD.org> CommitDate: 2026-08-08 19:58:25 +0000 devel/tinygo: Unmark BROKEN for now As pointed out by des in the PR referenced below, tinygo isn't broken yet; it's going to be broken soon (when Go 1.25 leaves the tree), but does build now. PR: 297237 devel/tinygo/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
In the meantime I see no reason to delay the switch, so I'll go ahead and commit it. In the future, I suggest we aim to switch the default to 1.N _at the latest_ when 1.N.2 comes out. This means we prepare a patch and request an exp-run around the time 1.N.1 hits the tree, which is usually about a month after 1.N.0. For the immediate future, this translates to the following schedule: - August: - 1.27.0, 1.26.6, 1.25.13 released and ported - we belatedly switch the default Go version to 1.26 in main, 2026Q3 remains on 1.25 - September: - 1.27.1 and 1.26.7 released and ported - we drop 1.25 from main - we create a PR for switching to 1.27 and request an exp-run - October: - 1.27.2 and 1.26.8 released and ported - we switch the default Go version to 1.27 in main, 2026Q4 remains on 1.26 This means devel/tinygo must expire before 2026Q4 gets branched. We should mark it DEPRECATED rather than BROKEN, and set the expiration date to 2026-09-30.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=43892f32d0588e1600c7962ca8ca69080fb60212 commit 43892f32d0588e1600c7962ca8ca69080fb60212 Author: Dag-Erling Smørgrav <des@FreeBSD.org> AuthorDate: 2026-08-02 19:30:29 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2026-08-08 20:08:21 +0000 Mk: Switch default Go version to 1.26 PR: 297237 Mk/bsd.default-versions.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to Dag-Erling Smørgrav from comment #13) I completely agree on N.2—that’s basically what I was getting at in comment #1 (“I’d like to … switch to 1.27 after a few months”). I think your entire timeline and approach is bang-on. Re: tinygo, I don’t see any particular reason to have it outlive 1.25. I’d just as soon see it scheduled for removal alongside 1.25.
Ah, re-reading your comment I think I may have misinterpreted. You thinking of removing 1.25 when 1.27.1 comes out (approx. the 15th) or at the end of the month? I don’t feel strongly either way, so if you do then I’ll defer to your judgment. All things being equal, I’d probably go for doing it earlier in the month, so that there’s a couple weeks to address any (highly-unlikely) fallout in main before 2026Q4 branches.
All we need to do is mark lang/go125 DEPRECATED with an expiration date of 2026-09-30 just like I already did for the two ports that depend on it and someone (usually rene@) will remove it before branching 2026Q4 in early October. There won't be any fallout since everything that remains will already depend on 1.26 or 1.27.