proposal: all: designate Go 1.16 as first Long Term Support version

[beoran]

Now that #44505 is accepted, and go 1.16 will be the official bootstrap compiler for Go language, I 'd like to propose an idea that I mentioned already in that thread. In many large organizations and for certain types of software development, such as life critical software, stability is of great importance. Even if the compiler has known issues, normally we run compiler test suite and avoid anything the compiler has problems with. What matters most is that the resulting artifacts of compilation of the same source code stay the same themselves for ease of verification and validation.

Currently, Go is released twice a year, and to keep using a supported Go compiler, we have to upgrade at least once a year, which is often too fast for these kinds of projects and environments. Therefore, I would like to see version 1.16 designated officially as the long term support version of Go, for use in organizations and situations as mentioned.

This would entail Go 1.16 keeps getting critical patches, and is available on the download web page as the LTS version, as well as some documentation about it's known issues. I leave it up to the Go team to suggest a duration for the LTS support but a period of 3 to 5 years seems reasonable.

While I think this might require some minimal extra effort, the Go team already will have to support Go 1.16 as it is the bootstrap version. So it seems to me this would not cause an undue burden on the Go team. Perhaps a few more bugs would have to be back-ported than usual, but this also would help keeping the bootstrap version of Go in good maintenance. These costs seem to be less than the great benefit to the go community of having an LTS version.

That's why I respectfully ask to consider this proposal.

[mdempsky]

the Go team already will have to support Go 1.16 as it is the bootstrap version.

Note that the support for Go 1.4 has been just the bare minimum to keep it working for purposes of bootstrapping, and we also minimize how much of the Go distribution actually needs to build with the bootstrap version. E.g., compiler bugs are avoided by compiling with inlining disabled during bootstrapping; we manually vendor code to get newer/fixed standard library features; we don't utilize the networking packages at all; and so on.

[changkun]

Not entirely sure what's the definition of long-term support, but isn't Go 1 has been long-term supported over more than 10 years and nothing breaks? Did I miss anything?

[beoran]

@changkun What you are talking about is the Go 1 compatibility promise. This is a feature of the language itself, not of the compiler and runtime. In this case LTS means long term support of a particular version of the compiler and runtime.

Edit: the importance of this is that not only the source code, but also the produced binaries stay the same. For some types of life-critical development, if the binaries change, the compiler as well as the effect the changes in the compiler have must be completely re-examined.

[beoran]

@mdempsky Isn't that one of the causes that makes it somewhat harder to contribute to developing the Go compiler? By investing a bit more effort in the bootstrap version of Go so it can also serve as an LTS version, it will be more comfortable to use than by letting it decay to a minimum viable version. In fact, the discomfort of using such a minimal v1.4 is the second most important reason for me why I don't contribute any code to this project.

[randall77]

@beoran You don't actually have to use 1.4 to bootstrap. You can use any other later version.
(Except that we require that you don't use any features introduced after 1.4, so that the distribution is still bootstrappable by someone else from 1.4. I think we have builders that verify that.)

[mdempsky]

Isn't that one of the causes that makes it somewhat harder to contribute to developing the Go compiler?

Yes, it's certainly an annoyance at times. But I think in the big scheme of things, it's not the biggest impediment to contributing to the Go compiler. Understanding the code base and how everything fits together tends to be the bigger issue.

In fact, the discomfort of using such a minimal v1.4 is the second most important reason for me why I don't contribute any code to this project.

I think this is getting off topic, but I'm not sure what discomfort you're referring to here. E.g., I typically bootstrap using whatever Go release I happen to have pre-installed. I only bother to bootstrap from Go 1.4 when I'm trying to reproduce a trybot bootstrap failure. (Typically the latter only happens when trying to introduce major new dependencies to the compiler; e.g., when we switched the compiler to use go/constant instead of its original c2go-translated code.)

[beoran]

Well I don' t want to go too far on this point but if 1.16 were both the bootstrap and the LTS, then it would be much easier to even get started, without having to rely on try bots and carefully having to avoid accidentally using recent features. Additionally the documentation of the LTS could remain available online to make very clear what the supported features actually are. But I think that's enough said on this.

More important for me is the point of long-term stability also at the binary level. Some kinds of Go software development, and Go development in certain kinds of organizations is difficult without an LTS version.

Furthermore, now that I think about it, Ubuntu has an LTS version 20.04 which also includes a Go compiler, v1.14 to be exact, and I suppose Ubuntu gives LTS for that as well. That's not bad, but it would probably be better if the Go team at least designated certain versions of the compiler as LTS, so this could be done in cooperation with the Ubuntu and other various other software distributions on Linux and other OS.

[jfesler]

I don't want to bifurcate the go community between those sticking to LTS, vs not (and the consequences of holding back modules from being able to use improvements that come only after 1.17+). As a module writer, I know I need to support current and previous; but after 1 year of a feature being matured, I can start depending on it. Without worrying about some LTS audience opting to stick to the stone ages.

[robpike]

As mentioned above, the compiler/language isn't the issue you're really after here. You'd also need support for the complete set of libraries and other dependencies required to build your software. Now it might be reasonable to expect the core libraries from 1.16 to continue to compile and work correctly with the old compiler, although it's a big demand, but it would require a contributor culture that also agrees to continue support. That seems much harder to achieve.

Although I think LTS is a great thing when there is constant flux, in the Go world with its guarantee of language stability it buys a lot less. The fact that you always have the source you need to build also reduces the need for LTS, which usually requires ABI stability as well.

In short, with all the care the team and the community put into keeping everything compiling for you, and with the existing mechanisms and promises in place, there isn't enough of a need for an extra level of long-term stability guarantee. The cost/benefit ratio is too high.

So while I understand your desire for stability, you already have so much it seems greedy to ask for more.

[beoran]

Far from me to want to be greedy, but you bring up an important point. Go language is open source, so if it is not in the resources of the Go team, I could maintain an unofficial LTS version myself, as you seem to suggest. I also don't want to cause any rifts in the go community, but if this is important to me I have to be willing to put in the needed work. If the feedback from the Go team is largely negative, then I will have to pursue that alternative.

[rsc]

Perhaps at some point we will establish longer support for Go versions, but that requires a lot of effort, and the mere fact of using Go 1.16 as the bootstrap toolchain is not enough justification.

[beoran]

@rsc: That is fair enough, it looks like I underestimated the effort needed. Seeing that many of the core members of the Go team oppose this: I withdraw my proposal.

However, if I am unable to do anything about this issue myself, then I'm looking foward to that future of longer supported Go versions. Maybe once the Go language itself becomes feature complete?

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

@beoran for what it's worth I think I'd argue Go is feature complete already and that the "long-term support" version of Go is Go 1. Every six months we issue an update to that LTS version. I know that's not how most people think of LTS.

I am very skeptical of the "freeze something and only make critical updates" approach to LTS. The problem is identifying the necessary critical updates once a version is no longer getting anywhere near the attention that the new releases are getting. Something that gets fixed as a trivial, seemingly inconsequential bug in a new version may actually be a security bug or DoS attack vector and not recognized as such in the older version and therefore not fixed. If you were going to do that kind of LTS well, I think you'd need a team dedicated to reviewing every change made in newer versions and trying to find some way that could manifest or be a necessary fix in the older versions. It would be a literal duplication (2X) of effort.

[beoran]

Yes, that's, not quite what comes to mind when I think of LTS, no. But your post made me laugh, so that's good, I guess :-)

But as I said, it's fair enough and I admit that in the worst case, a classic LTS would indeed mean that every issue that gets solved in "normal" Go needs to be considered for the LTS, and that is not a burden the Go team can take on easily.

Although the "freeze everything" approach you describe is how some Linux distros like Redhat make their money. Large corporations are willing to pay for that type of long-term stability. So the best short term-approach for me is to choose such an LTS Linux distribution and use the Go that comes with it.

Thanks for your consideration and time.

[ianlancetaylor]

I think that Red Hat is a great example here. Red Hat makes their money by providing long-term support for fixed releases because that is a valuable service and one that is expensive to provide. For Go LTS support it seems appropriate to look to a commercial support organization like Red Hat, not to the open source Go team.

Or alternatively look to an organization like Debian, that focuses on these support issues in a different way.