search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.66k stars 29.44k forks source link

Clarify plans (and maintain bypass mechanisms) for system compatibility checks after February 2025 #231623

Open murkvin opened 1 month ago

murkvin commented 1 month ago

Context

I'm following up on a change from earlier this year that caused the "Remote - SSH" VS Code extension to become incompatible with Amazon Linux 2 (among others) by enforcing a version requirement on glibc >= 2.28 and libstdc++ >= 3.4.25. As a temporary workaround, Microsoft made a change to allow VSCode to connect to incompatible OS versions until February of 2025.

Related links:

Request

With February 2025 fast approaching, it would be helpful to clarify what your action plan is for February. A concrete plan will help those of us who rely on VSCode (and the Remote - SSH extension) for our development workflows to understand what our options are. To kick off this line of communication, I have a few questions:

  1. Is there any plan to extend the February 2025 timeframe? 1a. If not, will support be going away at the beginning or the end of February?
  2. Will you be making an explicit change to disable legacy compatibility? 2a. What change (or changes) might that be? 2b. Will elements like /tmp/vscode-skip-server-requirements-check still exist?
  3. Would you be willing to provide a draft release with your planned changes so that we can be proactive in evaluating workarounds?

Closely related to my request for opening up a line of proactive communication, I'd also like to request that the legacy compatibility stay in place to whatever extent it is possible and practical to maintain. For users in many environments, pinning versions and missing out on security patches is a complete non-starter. We'd be forced to move to different tooling at least until we move to new, compatible systems.

As a user, I worry that I'll be "left behind" by VSCode despite being on a mainstream distribution's active LTS release.

isidorn commented 1 month ago

Thanks for reaching out. Let me try to answer your questions.

There are no plans to extend the February 2025 deadline. Compiler requirements for newer Node.js versions and the security push inside Microsoft will make it harder to support across all three architectures of the legacy server with the current sysroots.

Will support be going away at the beginning or the end of February?

Support will be removed in beginning of March 2025. February release of VS Code will be the last version to support legacy server

Will you be making an explicit change to disable legacy compatibility? Currently, there are a number of elements in play--the legacy server, a special /tmp/vscode-skip-server-requirements-check check, shell script checks, checks written in Rust, etc.

Yes, the following changes will be made: a) Removal of the pipeline that builds the legacy server https://github.com/microsoft/vscode/blob/main/build/azure-pipelines/linux/product-build-linux-legacy-server.yml b) Update the checks in cli https://github.com/microsoft/vscode/blob/main/cli/src/util/prereqs.rs to exit with an error on platforms that used legacy server c) Drop the support for legacy server use in the version check script https://github.com/microsoft/vscode/blob/a77885d9e879023f87c852d5f089efb1399a3e75/resources/server/bin/helpers/check-requirements-linux.sh#L14

Would you be willing to provide a draft release with your planned changes so that we can be proactive in evaluating workarounds?

Yes, this is a reasonable ask, we can provide a custom insiders build to test by December.

reukiodo commented 1 month ago

Will there be an announcement prior to the release in order to disable automatic updates? Or even better some method to automatically STOP automatic updates prior to this breaking change?

simozacca commented 1 month ago

Our research groups at London universities, along with many hundreds of other colleagues in similar academic environments worldwide, have been unable to upgrade our servers due to factors beyond our control. We hope you understand that, in certain contexts, especially in academia, financial constraints and administrative processes make such changes less feasible and significantly slower.

We would greatly appreciate it if a solution could be provided that allows us to continue using VSCode remotely on our outdated servers. A possible approach could be pinning a stable reference version that, while no longer maintained, could still be used by those in similar circumstances (which we believe is a considerable number of users).

We appreciate your understanding, as VSCode remains an essential resource for our publicly funded research.

reukiodo commented 1 month ago

Also, users of VSCode are not necessarily admins of the systems they utilize. Breaking VSCode users is just penalizing your users, especially when they are not in the ability to upgrade equipment they are required to use.

isidorn commented 1 month ago

Thanks for your feedback.

Yes there will be announcement. You may disable automatic updates of VS Code via the setting "update.mode": "none".

We will consider making the last version of VS Code that connect to an unsupported OS accessible from our docs.

adamcolon commented 1 month ago

I can assure you, many of us cannot have legacy systems upgraded. Many of us are clients and we have no control over the hardware, but we must manage and update code on them.

As long as you provide a path to ignore the check and keep using the software bypassing the lockout, we're fine.

tldr; there's no way for some of us to upgrade legacy hardware but we still need to do work on them