all: extend release support to "two release cycles"

[spf13]

Last year when Sierra was released it broke the existing 1.6 Go releases. By this point Go 1.7 was already released so according to the existing policy there was not a valid case for releasing a 1.6.x release.

This was captured in #16354

At the time a number of users and companies expressed concern with this policy and desired a working version for the prior release.

As we consider making changes to our release policy I propose that we add support for at least the current release and current-1 for functional work across all major platforms. Another way of saying the same thing given our current 6 month release schedule is that each major release will be supported for 1 year.

I'm happy to drive this and gather feedback as needed.

[minux]

While the Darwin case has a simple fix, most other incompatibility between major OS updates are much harder to fix, especially for those that don't maintain stable kernel ABI (e.g. FreeBSD on package net, and OpenBSD's change to 64-bit time_t, etc.) I suggest that we consider this on a case by case basis and only issue new minor release of the 2nd previous stable release when the fix is simple enough. Or perhaps the community could maintain a back port release that cherry picks high priority master changes to older release branches.

[rsc]

This issue is not about OS releases; that was just an example. The issue is about whether we should extend the period for "critical fixes" for a particular release from 1 release cycle to 1½ or 2 (six months to nine months or one year).

One argument for doing so is that otherwise there's no overlap in the support. One day, only release X gets critical updates; the next day release Y is out and X stops getting critical updates. If you're a company using Go, that means you have a bit of a step function in needing to update. Extending the support periods to overlap would give a clearer window, so that as long as you update in whatever the overlap is, you're always using a supported version of Go.

We know what the burden is. The question is whether there are significant (likely commercial) users who this would help or would make Go a more tenable solution for. I'd especially like to hear from them. A community-maintained back-port release is probably not sufficient in that case.

[4ad]

The issue is about whether we should extend the period for "critical
fixes" for a particular release from 1 release cycle to 1½ or 2
(six months to nine months or one year).

I think we should definitely do that because that is what users
think we already do. I have talked to several commercials users of
Go who would simply not believe me that we don't do that already.
They had such a strong expectation of this policy, they didn't even
dream of trying to find out if it's true.

One argument for doing so is that otherwise there's no overlap in
the support.

That is precisely the problem and the reason they didn't believe
me at first.

[rsc]

Based on discussion here and with @golang/proposal-review, let's extend the support by one release cycle: the minor releases to update Go 1.8 during the Go 1.9 cycle will continue during the Go 1.10 cycle, stopping when Go 1.10 is released. The security policy is already "two releases", so it stays the same.

[rsc]

TODO: Update docs and then close issue.

[spf13]

@rsc It's a small docs change, but I'm happy to take it on if you want.

[gopherbot]

CL https://golang.org/cl/37531 mentions this issue.