Historically, we've endeavored to do a new gopls release ~monthly, in order to stay up-to-date with dependencies and minimize delta. Typically we'd cut a new minor version (e.g. email@example.com) whenever there is a significant improvement that we'd like to highlight. At this point we'd create a new release branch (e.g. gopls-release-branch.0.9), and subsequently merge from master to the release branch whenever we cut patch releases (e.g. firstname.lastname@example.org).
There are some problems with this model that we'd like to solve:
Releasing is tedious. Releasing involves multiple CLs, smoke testing, writing release notes, etc. We are working on integrating with the release team's new Relui automation, which should make the process of releasing easier, but it doesn't eliminate the need for manual verification of releases, writing release notes, or promoting the prerelease.
Releasing is risky. For example, see x/tools/gopls: follow-up to golang/vscode-go#2406 (analyzer print statement breaking gopls) #54459. While we continue to invest in testing and benchmarking, it is unfortunately true that
a. gopls has significant technical debt that we're still paying down
b. gopls interacts heavily with the operating system, and so is subject to differing behavior across platforms (example)
c. gopls interacts with dozens of different editors and LSP clients, many of which have subtly different behavior (example)
d. gopls has no telemetry, and user reports are sparse and sporadic
I propose to address these problems by adopting a release policy more similar to that of the main Go distribution (albeit every 3 months rather than 6):
Only merge from master for *.*.0 patch releases. Instead of merging for each patch release, only merge when we initially cut our minor version release branches, corresponding to the *.*.0 patch release. Subsequent patch releases will contain only cherry-picked CLs, ideally only bug fixes.
Target minor releases every ~3 months. Try to stick to a schedule of releasing new minor versions every 3 months. This will allow a regular pace of new features, and allow us to coordinate with the Go release, but will reduce churn.
Let new minor versions soak in prerelease for longer. In the past, we've let prereleases soak for a few days, longer if we think they are risky. With this new policy, I think new minor versions should soak in prerelease for at least two weeks.
Heavily promote minor version prereleases. Recently we've tried promoting risky prereleases on gophers Slack, with moderate success. We can do more: a devlog, twitter post, or nightly channel for the main vscode-go extension. We can also encourage non-vscode LSP clients to have a nightly channel.
Fully automate patch releases. If subsequent patch releases consist only of a small number of bug fixes, it should be possible to fully automate them in Relui, including their release notes and publication.
Target patch releases every ~month. Since patch releases should be easy, releasing every month should no longer introduce significant toil.
Document this policy, for reference and to set expectations.