gopls: improve logic for staged rollouts

[findleyr]

Today, we released [email protected]. One of the reasons for choosing a .0 version is that .0 versions benefit from a staged rollout. This release contained several "risky" changes, so we thought a staged rollout was prudent.

And it was: we quickly discovered the importer bug https://go.dev/issue/61670 stemming from a logic error in a new importer algorithm (mea culpa).

Unfortunately, now we're in a dilemma: is it better to release v0.13.1 immediately (and thereby release v0.13.x immediately to everyone), or wait a day since the new bug seems unlikely for most users? We don't want to rush the rollout of other risky changes in [email protected], so we're going to wait until tomorrow morning for v0.13.1.

Ideally, we would not have to make this decision. I think it should be safe to roll out v0.13.1, even if v0.13.0 is still rolling out incrementally. We could do that by modifying the logic of okForStagedRollout slightly:

• change the signature to accept an optional current version
• if the current version is unset, or if the minor version of the current version matches the minor version of the new version, release immediately
• otherwise, consider the timestamp of the vx.x.0 version to see if the staged roll-out should proceed, per the current logic

CC @hyangah: what do you think?

[hyangah]

Sounds good. Will you send a change? Test code is here: https://github.com/golang/vscode-go/blob/3eafcb48099690dbd7f3b170b4b241020c837be7/test/gopls/update.test.ts#L110

[findleyr]

Yes, I will send a change.

[gopherbot]

Change https://go.dev/cl/514903 mentions this issue: src/language: update logic for staged rollout