Update Code to 1.89.0 - #6783

code-server-4.24.0-rc.1-linux-amd64.tar.gz with Code 1.89.0 is deployed at https://coder.jupyter.b-data.ch.

Functionality [modified by patches] tested and found to work:

• base-path
• cli-window-open
• local-storage
• marketplace
• proxy-url
• service-worker
• web view

Workspaces and Jupyter Notebooks also work fine:

• ms-toolsai.jupyter@2024.3.1
• ms-python.python@2024.4.1

Cross reference:

• Jupyter extension is outdated EclipseFdn/publish-extensions#740

@code-asher I have built as usual. Somehow code-server --version shows ... with Code 1.90.0.

JupyterLab Terminal

code-server --version

4.24.0-rc.1 fb2afbd9d62532be3952118adafff3972c63f3bc with Code 1.90.0

code-server Terminal

code-server --version

1.90.0
fb2afbd9d62532be3952118adafff3972c63f3bc
x64

I have no idea why. Just wanted to let you know.

Somehow code-server --version shows ... with Code 1.90.0

How strange! I believe it just reads lib/vscode/package.json. Maybe VS Code branched 1.89 off the wrong commit.

Yeah I checked and the package.json says 1.90.0. Oh maybe we should use the release/1.89 branch, it seems to be right there. I think maybe they put the 1.89.0 tag on the wrong commit. Or possibly they messed up the release branch and force pushed it.

Yeah I checked and the package.json says 1.90.0. Oh maybe we should use the release/1.89 branch, it seems to be right there. I think maybe they put the 1.89.0 tag on the wrong commit. Or possibly they messed up the release branch and force pushed it.

VS Code v1.89.0 is built off commit microsoft/vscode@b58957e.

I will update this merge request accordingly.

VS Code v1.89.0 is built off commit microsoft/vscode@b58957e.

I will update this merge request accordingly.

Updated on their side, too:

• April 2024 Endgame microsoft/vscode#210887 (comment) ff
• https://github.com/microsoft/vscode/releases/tag/1.89.0

@code-asher I would like to propose the following:

Release candidate (RC)

1. use the .0-releases of Code - OSS as base for a release candidate
   • in this case: Code - OSS v1.89.0 = code-server v4.24.0-rc.1¹
2. test, debug and fix; maybe do another RC-release
   • in this case: code-server v4.24.0-rc.2¹

👉 The .0-releases of Code - OSS have had some fundamental bugs. IMHO these should be used for release candidates only.

Release

1. use the .1-release of Code - OSS as base for a new [minor] code-server release
   • in this case: Code - OSS v1.89.1 = code-server v4.24.0¹
     ℹ️ There has always been a .1-release of Code - OSS
2. use the .2-release of Code - OSS as base for a new [patch] code-server release
   • in this case: Code - OSS v1.89.2 = code-server v4.24.1²
     ℹ️ Sometimes, there is a .2-release of Code - OSS

@code-asher With the "Alternative", the patch releases are in sync. And why not keep the minor releases in sync, too?
👉 I.e. Code - OSS v1.89.1 = code-server v4.89.1

It does sound reasonable to keep them in sync, unfortunately sometimes we make fixes or additions to code-server other than updating VS Code, so as soon as that happens we would be permanently out of sync, I think.

It does sound reasonable to keep them in sync, unfortunately sometimes we make fixes or additions to code-server other than updating VS Code, so as soon as that happens we would be permanently out of sync, I think.

IMHO updates other than Code - OSS are simply additional patch releases, i.e. .3, .4, etc.
👉 Most of these updates do not require a separate release; being part of the next [minor/patch] release is sufficient.

Breaking changes in code-server require updating the major version – according to SemVer.

Other than that, minor and patch releases remain in sync with upstream Code - OSS.

I would not be comfortable releasing a feature update as a patch, I think.

But I agree that those updates can just wait until the next release. I am open to experimenting with this, if we do come across a feature update that absolutely has to be released early for some reason then we can revisit.

I put out v4.89.0-rc.1!

An alternative would be to use semver builds v4.89.1+coder1 like k3s.io is using (e.g. v1.30.0+k3s1). I think going back to v1.89.1+coder1 is not an option ;)