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

[murkvin]

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:

• https://github.com/microsoft/vscode/issues/201129
• https://github.com/microsoft/vscode/issues/203375

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]

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]

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]

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]

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.