Admins will be upgrading ORNL GitLab Servers on Saturday, 16 May 2026, from 7 AM until 11 AM EST. Repositories will experience intermittent outages during this time.
@@ -13,7 +13,7 @@ If `gopls` is compiled for Go 1.23, it won't work for projects that require Go 1
Go only ever has two supported toolchains. With a new minor release, the second last Go toolchain is automatically end of life, meaning it won't receive security updates anymore.
Based on this, we align on the following policy for toolchain/builder upgrades:
Based on this, we align on the following policy for toolchain/builder upgrades for the unstable release:
1. Default toolchain (the `go` package) and builder (`buildGoModule`) are upgraded to the latest minor release of Go as soon as it is released.
As it is a mass rebuild, this package will be made against the `staging` branch.
@@ -42,4 +42,8 @@ Based on this, we align on the following policy for toolchain/builder upgrades:
If the package won't build with that builder anymore, the package is marked broken.
It is the package maintainers responsibility to fix the package and get it working with a supported Go toolchain.
For the stable release, we recognize that (1) removing a Go version, or updating the `go_latest` or `go` packages to a new Go minor release, would be a breaking change, and (2) some packages will need backports (e.g. for security reasons) that require the latest Go version.
Therefore, on the stable release, new Go versions will be backported to the `release-2x.xx` branch, but the old versions will remain, and `go`, `buildGoModule`, `go_latest`, and `buildGoLatestModule` will remain unchanged.
However, `rc` versions should not be backported to the stable branch.
