search

coder / code-server

VS Code in the browser
https://coder.com
MIT License
66.51k stars 5.45k forks source link

Update Code to 1.89.0 #6783

Closed benz0li closed 2 months ago

benz0li commented 2 months ago

Fixes https://github.com/coder/code-server/issues/6782

benz0li commented 2 months ago

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:

Workspaces and Jupyter Notebooks also work fine:

Cross reference:

benz0li commented 2 months ago

@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.

code-asher commented 2 months ago

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.

benz0li commented 2 months ago

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 https://github.com/microsoft/vscode/commit/b58957e67ee1e712cebf466b995adf4c5307b2bd.

I will update this merge request accordingly.

benz0li commented 2 months ago

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

I will update this merge request accordingly.

Updated on their side, too:

benz0li commented 2 months ago

@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[^1]
  2. test, debug and fix; maybe do another RC-release
    • in this case: code-server v4.24.0-rc.2[^1]

👉 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[^1] ℹī¸ 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[^2] ℹī¸ Sometimes, there is a .2-release of Code - OSS

[^1]: Alternative: code-server v4.24.1-rc.1 [^2]: Alternative: code-server v4.24.2-rc.1

benz0li commented 2 months ago

@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

code-asher commented 2 months ago

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.

benz0li commented 2 months ago

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.

code-asher commented 2 months ago

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.

code-asher commented 2 months ago

I put out v4.89.0-rc.1!

smerschjohann commented 1 month ago

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 ;)