doc: document/reassert that last two releases are supported equally

[FiloSottile]

The policy for what does and doesn't get backported is currently documented at https://golang.org/wiki/MinorReleases.

Our default decision should always be to not backport, but fixes for security issues, serious problems with no workaround, and documentation fixes are backported to the most recent two release branches, if applicable to that branch.

Fixes for experimental ports are generally not backported.

A “serious” problem is one that prevents a program from working at all. "Use a more recent stable version" is a valid workaround, so very few fixes will be backported to both previous issues.

This is pretty vague, and it detaches from practice in quite a few ways. We discussed a more complete framework that reflects the current reality with @dmitshur.

I propose we document it at https://golang.org/doc/devel/release.html#policy (in keeping with #34038) with the following text.

/cc @golang/osp-team

---

Backporting policy

Most recent major release. The following changes are are eligible for backporting to the latest major release.

• Security fixes, in their own release, according to the security policy.
• Fixes for serious problems with no workaround. A “serious” problem is one that prevents a program from working at all. This includes, for example, miscompilation issues.
• Early fixes for regressions and issues in new functionality. As the release matures, the bar for these changes gets higher: while the first minor release in a series will accept most fixes for user-visible regressions, after five months they will be mostly rejected. As more of the ecosystem upgrades, fixing regressions with workarounds becomes less and less valuable, and the tradeoff with stability shifts.
• Documentation changes that fix incorrect public docs.

Fixes for experimental ports are generally not backported.

Previous major release. The only fixes eligible for backporting to the previous major release (for example, to Go 1.10, once Go 1.11 has been released) are those that address external changes that would make the release unusable. This includes security fixes and platform compatibility fixes (for example, if a new version of an OS breaks Go programs).

We consider upgrading to the latest major release a valid workaround, and the purpose of maintaining the previous major release is only not to force users to upgrade unexpectedly, so pre-existing serious issues and regressions are only fixed in the latest major release.

[networkimprov]

I find this a little confusing, because fixes to the most-recent release are also called "backports". The above text seems to address only the previous release.

[FiloSottile]

Would changing "latest" into "most recent" here help?

The following changes are are eligible for backporting to the latest major release.

[networkimprov]

Ah, I didn't see that the bullet list and paragraph pertain to different categories. It would help if the policy had two subsection heads.

Re the policy, a lot of folks would rather not upgrade deployments to a new major release until they've had the chance to evaluate its performance in their systems, and iron out any wrinkles. So early in the life of a most-recent release, they'd want to see all backports land on both releases.

Tangentially, I think the best policy would be long-term-support versions of the toolchain & runtime, and a rolling-release of the stdlib... But that's prob outside the scope here :-)

[FiloSottile]

Edited it with paragraph headings, thank you.

Re the policy, a lot of folks would rather not upgrade deployments to a new major release until they've had the chance to evaluate its performance in their systems, and iron out any wrinkles. So early in the life of a most-recent release, they'd want to see all backports land on both releases.

That's why we still backport things that are necessary to stay on the previous major release, but after six months, there are very few regressions that can still be found, and stability becomes more important (as well as limited team resources).

[networkimprov]

It would help if the policy gave a time frame for full support of the previous release, e.g. 90 days. That would let deployment teams know the earliest date on which they might have to either roll out the most recent release, or consider custom builds.

[FiloSottile]

I'll find somewhere to link https://golang.org/s/release if that's what you mean?

[networkimprov]

No. The previous-release policy seems vague and perhaps contradictory:

the purpose of maintaining the previous major release is only not to force users to upgrade immediately

How long is "not immediately", i.e. how long will the previous release get all backports? It's apparently less than 6 months. Could the policy give a time frame?

The only fixes eligible for backporting to the previous major release ... are those that address external changes that would make the release unusable

For fixes outside that set, one apparently has to upgrade immediately?

A lot of sites would prefer to postpone major upgrades as long as possible, and some even skip over an entire cycle.

[bcmills]

@networkimprov, sites who intend to skip an entire cycle should be very careful to test the beta and/or RC releases of the next release they do intend to pick up, since the window for the previous release closes as soon as the new release occurs.

You really don't want to be in a situation where you're, say, stuck on 1.11 and neither 1.12 nor 1.13 works for you because of some 1.12 regression that you didn't detect until after the 1.13 release.

[bcmills]

For fixes outside that set, one apparently has to upgrade immediately?

Yes: if something non-critical is broken and has been for a long time, then it can presumably remain non-critically broken for a little while longer while you upgrade.

[FiloSottile]

Oh, I see what's unclear. What I am trying to say is that if you upgrade your Linux kernel and Go 1.12.5 stops working with it, and we only backport the fix to Go 1.13, you are now forced to upgrade to Go 1.13 immediately. You can't stay on Go 1.12 until you are ready.

OTOH, if you are running Go 1.12.5 and it was working for you, it's fine to say you need to upgrade to Go 1.13.2 to get some fix.

The difference is external forces.

[networkimprov]

It's awkward to be the only one asking about this; I hope I haven't misunderstood something basic.

But I'm startled to learn that regression backports cease on the day the next major release appears. I'd assumed that a previous release would be fully supported for 6 months. (Would anyone expect otherwise?)

Suppose I wait until 1.12.5 to upgrade from 1.11.x, and then discover a regression on the day 1.13 comes out, I'm outta luck? Either upgrade again to 1.13 or resort to a custom build?

What I suggested above is that regression backports cease at a later date, e.g. 90 days following the next major release, and that the policy should document the time frame.

The difference is external forces

A distinction between regressions and "external forces" seems arbitrary. If one could fully evaluate a deployed application running on a new release within a known period, that would surface any regressions before the backport window closes. But that's not achievable in many cases.

stuck on 1.11 and neither 1.12 nor 1.13 works for you because of some 1.12 regression that you didn't detect until after the 1.13 release.

@bcmills I gathered that fix would be backported to 1.13 since it broke something working in 1.11?

[bcmills]

I gathered that fix would be backported to 1.13 since it broke something working in 1.11?

Yes; but if you're still on 1.11 due to some unreported regression in 1.12, it may take a while to identify and backport the fix to 1.13, and in the meantime you'd either be stuck with the regression or stuck with an unsupported Go release.

So it's a risky situation either way — it's much less risky to either upgrade through every release, or ensure that you test the betas and RCs of the next release after you skip one.