vscode dependency - is it possible to get a "legacy" version?

[GitMensch]

The last one that has no vscode 1.6x dependency was 0.20.0.

Checking the revision history of package.json I see that it was increased to vscode 1.61 in version 0.21.0 to support platform specific extensions (to be able to include the matching graal-vm native built lemminx binary - which seems to be only used if Java is not available on the system) and later to enable a pre-release version (there's no way around it for that) to 1.63.

Rechecked: Those deployment parts seem to be the only reasons for the increased dependency. Are there more?
Manually downloading the vsix from open-vsx (it is not attached as a release artifact, only lemminx binaries are) and replacing the two occurrences of 1.61 with 1.52 in it allows not only installing but (given some tests) also using it with the 1.55 version that is installed on one of the machines I have to use and can't update myself.

Question:

• Would it be possible (and reasonable) to also provide a "not platform specific" version without the binary (which is still downloaded if no working java is found) - in this one having the dependency set back to 1.52?
• Would it be possible (and reasonable) to stick with a previous version in the repo (presumably 1.61) and only increase it during CI built of the pre-release version?

[rgrunber]

Almost seems like a bug that we need to bump the engine version for something that is only done at build-time. Some metadata regarding platform, and pre-release does make it into the vsix manifest, but I'm not sure why that would require an engine bump, given the properties are optional.

generic vs platform-specific

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="utf-8"?>
    <PackageManifest Version="2.0.0" xmlns="http://schemas.microsoft.com/developer/vsx-schema/2011" xmlns:d="http://schemas.microsoft.com/developer/vsx-schema-design/2011">
        <Metadata>
-           <Identity Language="en-US" Id="vscode-xml" Version="0.21.1" Publisher="redhat" />
+           <Identity Language="en-US" Id="vscode-xml" Version="0.21.1" Publisher="redhat" TargetPlatform="linux-x64"/>
            <DisplayName>XML</DisplayName>
            <Description xml:space="preserve">XML Language Support by Red Hat</Description>
            <Tags>xml,xsl,xsd,dtd,json,DTD,__ext_dtd,__ext_ent,__ext_mod</Tags>

non-pre-release vs. pre-release

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="utf-8"?>
    <PackageManifest Version="2.0.0" xmlns="http://schemas.microsoft.com/developer/vsx-schema/2011" xmlns:d="http://schemas.microsoft.com/developer/vsx-schema-design/2011">
        <Metadata>
-           <Identity Language="en-US" Id="vscode-xml" Version="0.21.1" Publisher="redhat" TargetPlatform="linux-x64"/>
+           <Identity Language="en-US" Id="vscode-xml" Version="0.21.2022072004" Publisher="redhat" TargetPlatform="linux-x64"/>
            <DisplayName>XML</DisplayName>
            <Description xml:space="preserve">XML Language Support by Red Hat</Description>
            <Tags>xml,xsl,xsd,dtd,json,DTD,__ext_dtd,__ext_ent,__ext_mod</Tags>
@@ -14,7 +14,7 @@
                <Property Id="Microsoft.VisualStudio.Code.ExtensionPack" Value="" />
                <Property Id="Microsoft.VisualStudio.Code.ExtensionKind" Value="workspace" />
                <Property Id="Microsoft.VisualStudio.Code.LocalizedLanguages" Value="" />
-               
+               <Property Id="Microsoft.VisualStudio.Code.PreRelease" Value="true" />

                <Property Id="Microsoft.VisualStudio.Services.Links.Source" Value="https://github.com/redhat-developer/vscode-xml.git" />
                <Property Id="Microsoft.VisualStudio.Services.Links.Getstarted" Value="https://github.com/redhat-developer/vscode-xml.git" />

Only 1.6x API I can think of that might force a bump anyways is Inlay Hints.

• @angelozerr , how likely would we be to adopt Inlay Hints provider in the future ?
• I don't think we could release this "legacy" vsix to the marketplace without complicating our release process. Since there's no "stream" for the engine versions, we would basically have to release the "legacy" vsix just before releasing the latest one. I assume VS Code would prevent installation of the incompatible one to take advantage of the fact that VS Code should try to install the latest compatible one.
• It should be simple to just bump the engine prior to a build, although it does add more complexity to the build process but then why not just rebuild it ? For the generic vsix, everything is there for it to be rebuilt as needed.

[angelozerr]

@angelozerr , how likely would we be to adopt Inlay Hints provider in the future ?

I don't see today some inlay hint usecases with XML.

[GitMensch]

Almost seems like a bug that we need to bump the engine version for something that is only done at build-time.

I'm really lucky to find someone that has the same understanding of this issue! And yes: releasing the version (then generic) then releasing it again (possibly with a .1 number increase) would solve the issue at both market places, without the need for an "extra" legacy one.
And yes: it would complicate the build process as package.json would have to be adjusted in between.
I think that the pre-release CI build could be easily adopted to always do this, without being an issue, correct?

[rgrunber]

Do you mean https://github.com/redhat-developer/vscode-xml/blob/main/Jenkinsfile ? That handles all marketplace releases (pre-release & formal releases).

@fbricon , what are your thoughts on supporting older versions of VS Code ? Seems like we could do it here (because the only 2 things that bumped the engine since ^1.52.0 were pre-releases/platform-specific), but I don't know how much demand there is for this, not to mention the added build complexity isn't appealing.

At the very least, modifying the engine value itself would be easy :

eg. npx gulp set_vscode_engine --engineVersion ^1.33.3

diff --git a/gulpfile.js b/gulpfile.js
index 47c8346..ed1f0bd 100644
--- a/gulpfile.js
+++ b/gulpfile.js
@@ -5,6 +5,7 @@ const cp = require('child_process');
 const server_dir = '../lemminx';
 const fse = require('fs-extra');
 const glob = require('glob');
+const argv = require('minimist')(process.argv.slice(2));
 
 gulp.task('tslint', () => {
     return gulp.src(['**/*.ts', '!**/*.d.ts', '!node_modules/**'])
@@ -34,6 +35,18 @@ gulp.task('build_server_with_binary', function(done) {
        done();
 });
 
+gulp.task('set_vscode_engine', function(done) {
+    const json = JSON.parse(fse.readFileSync("./package.json").toString());
+    const engineVersion = (!argv.engineVersion) ? '^1.52.0' : argv.engineVersion;
+    const insiderPackageJson = Object.assign(json, {
+        engines: {
+            vscode: `${engineVersion}`
+        }
+    });
+    fse.writeFileSync("./package.json", JSON.stringify(insiderPackageJson, null, 2));
+    done();
+});
+
 gulp.task('prepare_pre_release', function(done) {
     const json = JSON.parse(fse.readFileSync("./package.json").toString());
     const stableVersion = json.version.match(/(\d+)\.(\d+)\.(\d+)/);