The news of the time interval is that Go 1.18 has been released. There are a number of famous big changes in Go 1.18; obviously generics, but I think that official fuzzing support and workspaces are likely to have a bigger impact in the near future (certainly I think that more people should use fuzzing than should touch generics right now). But there's another important change, which is that module mode is now mandatory, although the release notes don't directly say that.

(Dropping support for GOPATH based local builds has been coming for some time, although it was pushed back one release from what was initially planned, from Go 1.17 to Go 1.18. I noted this when Go 1.17 was close to release, but I don't think the Go developers ever said anything about why the change happened.)

This means that Go 1.17 is the last Go release that can be used to build non module aware programs from a local source tree. For now, Go 1.18 continues to be able to build non module aware programs from a supported more or less public repository, with 'go install ...@latest', but I suspect that support for that is not long for this world and of course you need everything to be accessible. See what you can and can't build in Go's module mode for more.

In theory you can create a go.mod file for every program you have that's still without it (hopefully they're third party programs; if not, you need to update things). In practice, it's been my experience that creating a working go.mod file can take some work and fiddling for various reasons beyond the scope of this entry (although perhaps that's gotten better recently, and I haven't looked to see if workspaces help here). Also in theory, people should already have been adding go.mod files to their programs and will now have even more reason to do that; in practice, there are any number of perfectly good old Go programs that you may still find valuable that their authors consider 'done'.

(A program that previously gave me problems with a manual modularization did build with 'go install ...@latest', although I'm not sure it used the same versions of other packages.)

Because of all of this, you might want to consider planning to save a copy of Go 1.17. You probably don't want to freeze it just yet, since there may be future patch releases of Go 1.17 before it drops out of support when Go 1.19 is released, but at least you can plan for it and remind yourself to set it aside and not discard it now that 1.18 is out. My own view is that you should plan to save already compiled binaries; there's no guarantee that future versions of Go will be able to build Go 1.17 or that the Go people will keep the pre-built binaries around forever.

(Recent versions of Go require the Go source tree to have some go.mod files in strategic places. Old versions of Go don't have them, so you can run into problems. I care about old versions of Go because I sometimes use a machine running FreeBSD 10, which was last officially supported in Go 1.12, although recent versions of Go do seem to still work on it.)

There are limits to how useful this might be on some platforms, such as OpenBSD, but on mainstream platforms it's very likely that a Go 1.17 binary that works today will keep working even with future versions of the operating system. Fortunately modern Go releases are essentially indifferent to where they're put, and if for some reason you do care (for example for completely reproducible binaries, although the situation covered in Reproducing Go binaries byte-by-byte may have changed since then) you can always rebuild Go 1.17 from source with itself.