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.

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

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

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 :-)

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).

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.

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

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.

@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.

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.

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.

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?

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.

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

It would be interesting to know how widespread this preference is, and what motivates it.

E.g., my first assumption was this only affects stubborn enterprise customers (who presumably could afford support contracts). But until Debian's latest stable release earlier this year, they were still shipping Go 1.7. Ubuntu 16.04LTS and 18.04LTS provide Go 1.6 and Go 1.10, respectively. Presumably other Linux distros are similarly affected.

Honestly I would expect that most large sites skip releases. I would be astonished if they adopt every release. At a large site each new release requires full re-qualification and testing. Nobody has time for that, unless they anticipate some large benefit.

(That's not to say that we need to do anything different. Our resources are limited. There is clearly space for commercial support organizations.)

Ubuntu 16.04LTS and 18.04LTS provide Go 1.6 and Go 1.10, respectively

That is a great argument for LTS releases.

Honestly I would expect that most large sites skip releases.

[cries in security engineer]

✋️👍

No one's addressed #34536 (comment)

Should I open a new issue to suggest changing the regression-backports window for previous releases?

I think the current text reflects the reality of the current policy, and it would be good to document it properly before we discuss changing it. If you are ok with this text going into release.html and then discussing changing the policy it reflects in another proposal, I think that would be a good way forward.

Then I think you should add a sentence to the effect of "Any regressions found in the previous release will not be fixed."

EDIT: filed #34622

Then I think you should add a sentence to the effect of "Any regressions found in the previous release will not be fixed."

That's not the current policy, serious regressions without workaround are still fixed, but are only backported to the latest major release, because we consider it ok to make someone who is upgrading to Go 1.12 late and finds a regression simply jump forward to Go 1.13.

Sorry I meant "Any regressions found in the previous release will not be fixed in that release."

The current language could be misinterpreted. The above makes it clear.

Does that add anything over "The only fixes eligible for backporting to the previous major release [...] are those that address external changes that would make the release unusable."?

Indeed it does. The language you quote is easily misinterpreted, especially if you assume (as most would) that a previous release is fully supported.

"External changes" could be read to mean CLs produced outside the core team, for example.

Updated the last paragraph to

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.

Ok, thanks.

I don't understand the rewording, or else how it's different from what I wrote.

For concreteness, if the most recent release was Go 1.14:

• If the bug was introduced in Go 1.13, then either both Go 1.13 and Go 1.14 get the fix, or neither do.
• If the bug was introduced in Go 1.14, then clearly only Go 1.14 gets the fix.

No other final comments, so accepting.

I believe that https://golang.org/wiki/MinorReleases now states the agreed policy (it was corrected as part of #37097).

I believe the agreed policy is also stated at golang.org/x/website/content/static/doc/devel/release.html.

So I don't think there is anything else to do here. Closing. Please comment if you disagree.

@ianlancetaylor Issue #37097 was about a problem on the Go-Release-Cycle page.

I spotted a problematic statement in the MinorReleases page; filed #40206 about it.

I don't believe we have a better place we can link to other than Russ' comment in this issue when referencing this aspect of the release policy. The https://golang.org/wiki/MinorReleases page was made less misleading in #40206, but it seems more needs to be done before this can be closed.