Repository navigation
chore!: drop support for Coder versions older than 2.29 - #383
Merged
Merged
Conversation
Currently, the plugin accepts any Coder deployment and CLI, down to v2.2.0. To stay compatible with that range, the CLI manager runs `coder version` before most commands to decide which flags it can pass. This adds a CLI call to every operation, and when that call fails, the CLI manager silently drops flags such as the ones that select keyring storage. This commit raises the minimum supported version of both the Coder server and the CLI to v2.29.0, in line with the VS Code extension. The REST client checks the server version during sign-in, before any other request, and the CLI setup checks the version of the downloaded or cached CLI. An unsupported version stops the sign-in with a message that asks the user to upgrade. The CLI does not have to match the server version, so deployments that distribute the CLI separately keep working as long as it meets the minimum. Every CLI flag the plugin relies on is available from v2.29.0, so the CLI manager no longer detects features per version and always passes these flags. As a result, the settings page and the documentation no longer mention version-specific behavior, and the warning about keyring storage being unavailable on older CLIs is gone. - resolves https://linear.app/codercom/issue/JET-40/
This commit brings the latest dependency and Gradle wrapper updates from main into the branch.
this seemed like a useful feature to me, and perhaps could be used similarly in the future. if we're getting rid of version-pinned feature flags, is there a replacement? |
jeremyruppel
approved these changes
Nov 4, 2026
matifali
approved these changes
Nov 4, 2026
matifali
changed the title
Collaborator
Author
Well for now we no longer need it because of the minimum version requirement. I usually tend to keep it simple and remove any code that is not needed at the time. If and when we will have to gate some new feature against a specific version, then I guess we will add back some of the code. |
Currently, the changelog lists the removal of support for Coder versions older than v2.29.0 under a regular removed section. The release workflow builds the draft release notes from the unreleased changelog section, so neither the changelog nor the release notes make it clear that users on older Coder deployments or CLI binaries can no longer connect after upgrading the plugin. This commit moves the entry to a breaking changes section and spells out that connecting with an older deployment or CLI now stops with an upgrade message, so the changelog and the generated release notes both call it out as a breaking change.
Currently, the branch is behind main, which has since added WebSocket-based progress for workspace actions. The workspace progress watcher in main only uses WebSockets when the CLI feature detection reports version 2.22 or newer, while this branch removes the feature detection because every supported version is at least 2.29. This merge keeps the feature detection removed, and the environment now always starts the progress watcher with WebSockets enabled. The watcher still falls back to REST polling whenever a stream is unavailable, so the changelog describes that fallback instead of support for older deployments. The start workspace tests from main use the shorter CLI call without feature flags, the environment tests no longer toggle WebSocket support, and the polling test now covers the fallback while no log stream is open. The changelog lists the breaking change ahead of the WebSocket progress entry.
Collaborator
Author
Done |
Currently, the start workspace tests expect the stdout line from the fake CLI to arrive before its stderr line. The process runner reads stdout and stderr on separate threads and reports each line as soon as its reader receives it, so the order between the two streams depends on thread scheduling, and the tests fail intermittently on main. With this change, the tests check the lines from both streams without depending on their relative order. The live progress test waits until the first two lines arrive instead of polling for each one in sequence, makes sure the CLI is still running at that point, and checks the final stderr line once the command returns, because the process runner delivers every line before it returns.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, the plugin accepts any Coder deployment and CLI, down to v2.2.0. To stay compatible with that range, the CLI manager runs
coder versionbefore most commands to decide which flags it can pass. This adds a CLI call to every operation, and when that call fails, the CLI manager silently drops flags such as the ones that select keyring storage.This commit raises the minimum supported version of both the Coder server and the CLI to v2.29.0, in line with the VS Code extension. The REST client checks the server version during sign-in, before any other request, and the CLI setup checks the version of the downloaded or cached CLI. An unsupported version stops the sign-in with a message that asks the user to upgrade. The CLI does not have to match the server version, so deployments that distribute the CLI separately keep working as long as it meets the minimum.
Every CLI flag the plugin relies on is available from v2.29.0, so the CLI manager no longer detects features per version and always passes these flags. As a result, the settings page and the documentation no longer mention version-specific behavior, and the warning about keyring storage being unavailable on older CLIs is gone.