Go release support policy

[mvdan]

CUE is useful as a command-line utility, enabling commands like cue eval or cue export, and also as a set of Go libraries which power the official CLI. When a third party project uses CUE as a Go library, they choose what Go version to use for their builds. For that reason, we need to have a policy in place to define which range of Go versions we aim to support at any given time.

Go releases a new major version every six months. The Go project also backports important and security fixes to two Go versions at a time, as described in their security policy:

Fixes are prepared for the two most recent major releases and the head/master revision.

For example, as of September 2022, the latest stable version of Go is 1.19.1, part of the 1.19 major version (note that Go calls these “major” rather than “minor”, unlike semver). This means that the Go 1.18 and 1.19 major versions are fully supported, both receiving backports for bug fixes. The Go 1.17 major version stopped being supported once 1.19 was released on August 2nd 2022, and its last version was 1.17.13.

We don’t have a Go release support policy right now. Implicitly, we currently support Go 1.17 and 1.18, both of which are tested via our CI. Newer Go versions are likely to work well, given Go’s strong backwards compatibility guarantees. Older Go versions may not work; for example, if we started using generics added in Go 1.18, then older Go versions like 1.16 or 1.17 would fail to build.

We would like to implement a Go release support policy and request feedback on the two options below.

Option A: two Go versions

The first option we have is to follow upstream: only support two stable major versions of Go. As of September 2022, this would mean we would only support Go 1.18 and later. Since Go releases come every six months, users of the latest version of our Go libraries would have up to twelve months to keep their Go version up to date.

This is the typical policy for most Go libraries. It is understood that, if a user cannot keep their Go version up to date, they can remain on a slightly older version of a Go library.

Option B: three Go versions

The second option is a more conservative version: supporting three stable major versions of Go rather than two. This adds an extra six months of time for library users to update their Go version, but it also has its drawbacks. The oldest stable version would be unsupported by upstream, and CUE would need to wait an extra six months to adopt newer Go standard library or language features.

Note that the Go release support policy would apply to the latest development version, master. For example, if CUE version 0.4.0 was released supporting Go 1.15 and later, future 0.4.x versions would continue to do so. Only a major version bump, like 0.5.0, could increase the minimum.

Feedback requested!

We want to hear from the CUE community:

• Is supporting two Go major versions at a time enough for your use case?
• If not, is there a particular reason why, such as difficulty in upgrading Go versions?
• Would three Go major versions make a significant difference?

Any other thoughts or input are also very welcome.

[nyarly]

Two major versions when a new CUE version is released sounds fine to me.

[wonderflow]

Option A works for us.

[mvdan]

Thanks all for the responses so far. It sounds like we're going to go with option A: support two Go versions at once for each CUE release.

For the sake of giving CUE users one more chance to pitch in, we're placing this proposal in a one-week final comment period. Assuming there are no comments against the proposal in the coming week, we will implement the proposal for CUE v0.5: it would require Go 1.18 or later, as the latest Go release is currently 1.19.

It is worth noting that dropping support for older Go versions would likely break building CUE on Go 1.17, for example, as we start using bits of generics in the internals like the evaluator.

[myitcv]

For the record, option A was chosen in 0292e7f.

[mvdan]

Like Paul says, option A was first applied in https://review.gerrithub.io/c/cue-lang/cue/+/545975, and later properly documented via https://review.gerrithub.io/c/cue-lang/cue/+/1176770. Closing as accepted and completed.