Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/tools/gopls: design/document new release policy #55267

Closed
findleyr opened this issue Sep 20, 2022 · 1 comment
Closed

x/tools/gopls: design/document new release policy #55267

findleyr opened this issue Sep 20, 2022 · 1 comment
Assignees
@findleyr
Labels
Documentation FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
gopls/v0.11.0

Comments

@findleyr
Copy link
Contributor

Background

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. gopls@v0.9.0) 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. gopls@v0.9.1).

Problems

There are some problems with this model that we'd like to solve:

  1. 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.
  2. 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
  3. Historically, releases haven't followed the spirit of semver. While we try to associate minor versions with "significant" changes, we have introduced new features in patch versions. Because we have been merging from master, there is also no reason to expect that patch releases are incrementally more stable: we introduced breakages such as x/tools/gopls: follow-up to golang/vscode-go#2406 (analyzer print statement breaking gopls) #54459 in patch releases.

Proposed Change

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.

CC @golang/tools-team
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Sep 20, 2022
@gopherbot gopherbot added this to the Unreleased milestone Sep 20, 2022
@findleyr findleyr self-assigned this Sep 22, 2022
@findleyr findleyr modified the milestones: Unreleased, gopls/v0.10.0 Sep 22, 2022
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/446863 mentions this issue: gopls/doc: clean up README and add a release policy

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Jan 7, 2023
@bsiegert
gopls: update to 0.11.0
9f0827d 
gopls/v0.11.0

This is a small release containing new integrations of vulnerability analysis.

Vulnerability analysis for go.mod files can be enabled by configuring the
"vulncheck" setting to "Imports". For more information on vulnerability
management, see the Vulnerability Management for Go blog post.

Support changes

This release removes support for the "experimentalUseInvalidMetadata" setting,
as described in the v0.10.0 release. Other settings slated for deprecation in
that release remain temporarily supported, but will be removed in v0.12.0.

New Features

- Analyzing dependencies for vulnerabilities
- Additional checks for the loopclosure analyzer

gopls/v0.10.0

This release contains initial support for standalone packages and package
renaming. Please see below for more details.

We are also changing our release policy to better align with semver.

Support changes

This version of gopls contains changes to our release policy, deprecates
support for some older Go versions, and deprecates support for several
experimental features.

New release policy

As described in golang/go#55267, we are tightening our release policy to better
follow semver, increase stability, and reduce release-related toil. Significant
new features will only be introduced in *.*.0 patch versions, and subsequent
patch releases will consist only of bugfixes. For example, this version
(v0.10.0) introduces several new features, described below. Subsequent v0.10.*
releases will contain only bugfixes.

Final support for Go 1.13-1.15

Consistent with the above release policy and our stated support window, the
v0.10.* minor version will be the final set of releases to support being used
with Go 1.13-1.15. See golang/go#52982 for details.

Gopls will pop up a warning if it resolves a version of the go command that is
older than 1.16. Starting with gopls@v0.11.0, gopls will cease to function when
used with a go command with a version older than 1.16.

Deprecated experimental features

The following experimental features are deprecated, and will be removed in
gopls@v0.11.0:

  * experimentalWorkspaceModule (golang/go#52897): this feature has been
    replaced by go.work files. See our documentation for information on how to
    use go.work files to work on multiple modules.
  * experimentalWatchedFileDelay (golang/go#55268): LSP clients should instead
    be responsible for buffering workspace/didChangeWatchedFiles notifications.
  * experimentalUseInvalidMetadata (golang/go#54180): we are going to focus
    instead on improving diagnostics for broken workspaces.

New Features

Support for "standalone packages"

Gopls now recognizes certain files as "standalone main packages", meaning they
should be interpreted as main packages consisting of a single file. To do this,
gopls looks for packages named main containing a single build constraint that
matches one of the tags configured by the new standaloneTags setting.
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Jan 18, 2023
@bsiegert
gopls: update to 0.11.0
4e10421 
gopls/v0.11.0

This is a small release containing new integrations of vulnerability analysis.

Vulnerability analysis for go.mod files can be enabled by configuring the
"vulncheck" setting to "Imports". For more information on vulnerability
management, see the Vulnerability Management for Go blog post.

Support changes

This release removes support for the "experimentalUseInvalidMetadata" setting,
as described in the v0.10.0 release. Other settings slated for deprecation in
that release remain temporarily supported, but will be removed in v0.12.0.

New Features

- Analyzing dependencies for vulnerabilities
- Additional checks for the loopclosure analyzer

gopls/v0.10.0

This release contains initial support for standalone packages and package
renaming. Please see below for more details.

We are also changing our release policy to better align with semver.

Support changes

This version of gopls contains changes to our release policy, deprecates
support for some older Go versions, and deprecates support for several
experimental features.

New release policy

As described in golang/go#55267, we are tightening our release policy to better
follow semver, increase stability, and reduce release-related toil. Significant
new features will only be introduced in *.*.0 patch versions, and subsequent
patch releases will consist only of bugfixes. For example, this version
(v0.10.0) introduces several new features, described below. Subsequent v0.10.*
releases will contain only bugfixes.

Final support for Go 1.13-1.15

Consistent with the above release policy and our stated support window, the
v0.10.* minor version will be the final set of releases to support being used
with Go 1.13-1.15. See golang/go#52982 for details.

Gopls will pop up a warning if it resolves a version of the go command that is
older than 1.16. Starting with gopls@v0.11.0, gopls will cease to function when
used with a go command with a version older than 1.16.

Deprecated experimental features

The following experimental features are deprecated, and will be removed in
gopls@v0.11.0:

  * experimentalWorkspaceModule (golang/go#52897): this feature has been
    replaced by go.work files. See our documentation for information on how to
    use go.work files to work on multiple modules.
  * experimentalWatchedFileDelay (golang/go#55268): LSP clients should instead
    be responsible for buffering workspace/didChangeWatchedFiles notifications.
  * experimentalUseInvalidMetadata (golang/go#54180): we are going to focus
    instead on improving diagnostics for broken workspaces.

New Features

Support for "standalone packages"

Gopls now recognizes certain files as "standalone main packages", meaning they
should be interpreted as main packages consisting of a single file. To do this,
gopls looks for packages named main containing a single build constraint that
matches one of the tags configured by the new standaloneTags setting.
@golang golang locked and limited conversation to collaborators Nov 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@findleyr findleyr

Labels
Documentation FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
gopls/v0.11.0
Development

No branches or pull requests
2 participants
@gopherbot @findleyr