Support publishing pre-release versions

The client UX for pre-release versions - https://code.visualstudio.com/updates/v1_63#_pre-release-extensions
How to publish pre-release versions - https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions

We have some experimental features and whether to put them in the stable versions depends on the feedback from users. The pre-release channel is a good way to collect early feedback. Here is a proposal about how our extension can use the pre-release channel to release insider versions.

Background

Channels

for VS Code insider users, the default channel is insider channel
for VS Code stable users, the default channel is stable channel
user can manually switch to another channel easily
for stable channel users, they can get auto-update for newest stable versions
for insider channel users, they can get auto-update for newest stable and pre-release versions (always the newest one)
for existing users, they will not automatically get the pre-release versions, regardless of the VS Code version

Publishing

directly pass an argument when vsce publish, see https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions

vsce publish --pre-release

Proposal

Versioning

Schema

for stable versions, the current versioning, major.minor.patch, e.g., 1.3.0
for pre-release versions, use major.minor.YYYYMMDDHH, e.g., 1.3.2022011915

Tips

This can keep the pre-release versions greater than those stable versions in the same minor version.
At runtime, if we want to distinctguish the two versions, we can just check the patch version.
Limitation: Can't release 2 pre-release versions in the same hour.

Repository engineering

Here I just propose a similar branch model with https://nvie.com/posts/a-successful-git-branching-model/. To keep our current repository managing and engineering, this proposal includes two main branches: develop for developing and master for keeping stable version

Branches

develop: the develop branch for releasing pre-release version
- we should make develop branch as the default branch of this repository
master: the branch for keeping stable version

Management

For all commitments, we will merge them into develop branch
When release a new stable version

1.Cherry pick some commitments from develop branch into master manually
2.Release a new stable version in master branch
3.Release a new pre-release version in develop branch
Create nightly pre-release build for develop branch
- A script will help to modify the current patch version in package.json with the current timestamp, see the version schema above
- When no new commit compared to last pre-release, we can just cancel this pre-release
For hot fixes, they should be merged into both develop branch and master branch

I think the main annoyance we may introduce is for an experimental contribution that makes it into insider and causes merge conflicts on some/many contributions from stable branch (changes from stable may fail the auto cherry-pick into insider).

@fbricon

I have edited the previous proposal to make it clearer and feasible. Meanwhile, I plan to adopt this model recently in Gradle for Java first to see if there is any gap.

cc: @fbricon @rgrunber @snjeza @akaroml @testforstephen @Eskibear @jdneo for more comments.

Gradle for Java extension has supported the pre-release channel.

you can see the pre-release version is recommended in vscode-insiders

and the stable version is recommended in vscode stable

after installed, you can also switch to the other channel

For the branch management, the Gradle for Java extension uses develop branch to merge all commits and publish nightly build. When releasing, all needed commits should be cherry picked into main branch. You can check https://github.com/microsoft/vscode-gradle/blob/de525424751231be5415f661318ba459f72da62b/.azure-pipelines/vscode-gradle-nightly.yml#L77-L108 for pipeline details.

@rgrunber

Hi @rgrunber, currently the pre-release channel has two requirements:

engine in package.json is greater than 1.63.0, see: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions
vsce in our Jenkins file should have a greater version than 2.5.0, see: https://github.com/microsoft/vscode-vsce/releases/tag/v2.5.0

For the engine part, do we have any other concerns about updating this version (about Theia support)? currently it's 1.61.0.

For the vsce part, I just find we strict the vsce verison in #2195, can we find a way to use the new vsce verison?

Ok, so we're publishing pre-releases now.

One thing worth noting, this could exacerbate issues surrounding excessive storage for heavy pre-release users. I'm assuming each new snapshot is getting its own folder :

$ pwd
/home/rgrunber/.vscode/extensions
[rgrunber@altrez extensions]$ ls -1 | grep redhat.java | xargs du -sh
138M	redhat.java-1.6.0-linux-x64
138M	redhat.java-1.7.2022051209-linux-x64

$ pwd
/home/rgrunber/.config/Code/User/globalStorage/redhat.java
[rgrunber@altrez redhat.java]$ 
[rgrunber@altrez redhat.java]$ 
[rgrunber@altrez redhat.java]$ du -sh * 
22M	1.5.0
22M	1.6.0
22M	1.7.2022051209

@rgrunber

@rgrunber Great! As for the storage issues:

.vscode/extensions might not be a problem since VS Code will automatically delete the old folder when auto-updating the extension.
But the globalStorage will not be deleted automatically. IMO we need to discuss some mechanism to clean the old folders (~22MB for each in your sample)

IMO we need to discuss some mechanism to clean the old folders

This problem exists for all extensions with pre-release. I suggest that we talk to vscode team first, it would be good if they can do the cleanup things.

We could always add the logic to

vscode-java/src/extension.ts

Line 999 in 72633ab

async function cleanJavaWorkspaceStorage() {

but having it done automatically would be nicer.

One reason for the globalStorage size, is that libraries (eg. jars) that are embedded in other jars (eg. org.eclipse.m2e.maven.indexer embeds a bunch of lucene jars), and need to be added to the classpath at runtime, are placed there (I don't think the classpath can reference a jar within another jar). So if we just reduce the usage of that, it should help.

The good news is that M2E 2.0 (assuming we can update from 1.18.0) should eliminate those jars and maybe a few others eclipse-jdtls/eclipse.jdt.ls#2085

The good news is that M2E 2.0 (assuming we can update from 1.18.0) should eliminate those jars and maybe a few others eclipse/eclipse.jdt.ls#2085

In this way, will the updating to the M2E 2.0 eliminate all of them or just most of them?

It should eliminate some of the ones coming from the maven.indexer bundle. Here are the current contents I see for jars :

972K ./46/0/.cp/jdimodel.jar
 12K ./49/0/.cp/lib/launchingsupport.jar
408K ./50/0/.cp/lib/jsoup-1.14.2.jar
 64K ./50/0/.cp/lib/remark-1.2.0.jar
 20K ./54/0/.cp/jars/archetype-catalog-2.4.jar
172K ./54/0/.cp/jars/archetype-common-2.4.jar
 24K ./54/0/.cp/jars/archetype-descriptor-2.4.jar
 20K ./54/0/.cp/jars/archetype-registry-2.4.jar
576K ./54/0/.cp/jars/commons-collections-3.2.2.jar
172K ./54/0/.cp/jars/commons-io-2.2.jar
204K ./54/0/.cp/jars/commons-lang-2.1.jar
320K ./54/0/.cp/jars/dom4j-2.1.3.jar
 28K ./54/0/.cp/jars/jchardet-1.0.jar
152K ./54/0/.cp/jars/jdom-1.0.jar
 32K ./54/0/.cp/jars/maven-invoker-2.1.1.jar
 64K ./54/0/.cp/jars/oro-2.0.8.jar
8.0K ./54/0/.cp/jars/plexus-velocity-1.1.8.jar
384K ./54/0/.cp/jars/velocity-1.5.jar
260K ./59/0/.cp/jars/indexer-core-6.0.0.jar
1.6M ./59/0/.cp/jars/lucene-analyzers-common-5.5.5.jar
424K ./59/0/.cp/jars/lucene-backward-codecs-5.5.5.jar
2.3M ./59/0/.cp/jars/lucene-core-5.5.5.jar
144K ./59/0/.cp/jars/lucene-highlighter-5.5.5.jar
136K ./59/0/.cp/jars/lucene-join-5.5.5.jar
 36K ./59/0/.cp/jars/lucene-memory-5.5.5.jar
248K ./59/0/.cp/jars/lucene-queries-5.5.5.jar
396K ./59/0/.cp/jars/lucene-queryparser-5.5.5.jar
228K ./59/0/.cp/jars/lucene-sandbox-5.5.5.jar
 52K ./60/0/.cp/jars/aether-connector-okhttp-0.17.8.jar
 44K ./60/0/.cp/jars/cdi-api-1.0.jar
 56K ./60/0/.cp/jars/commons-cli-1.4.jar
204K ./60/0/.cp/jars/commons-io-2.5.jar
492K ./60/0/.cp/jars/commons-lang3-3.8.1.jar
512K ./60/0/.cp/jars/guice-4.2.1-no_aop.jar
280K ./60/0/.cp/jars/jansi-1.17.1.jar
8.0K ./60/0/.cp/jars/jsr250-api-1.0.jar
 60K ./60/0/.cp/jars/maven-artifact-3.8.1.jar
 16K ./60/0/.cp/jars/maven-builder-support-3.8.1.jar
284K ./60/0/.cp/jars/maven-compat-3.8.1.jar
620K ./60/0/.cp/jars/maven-core-3.8.1.jar
 96K ./60/0/.cp/jars/maven-embedder-3.8.1.jar
212K ./60/0/.cp/jars/maven-model-3.8.1.jar
188K ./60/0/.cp/jars/maven-model-builder-3.8.1.jar
 48K ./60/0/.cp/jars/maven-plugin-api-3.8.1.jar
 28K ./60/0/.cp/jars/maven-repository-metadata-3.8.1.jar
148K ./60/0/.cp/jars/maven-resolver-api-1.6.2.jar
 48K ./60/0/.cp/jars/maven-resolver-connector-basic-1.6.2.jar
176K ./60/0/.cp/jars/maven-resolver-impl-1.6.2.jar
 68K ./60/0/.cp/jars/maven-resolver-provider-3.8.1.jar
 40K ./60/0/.cp/jars/maven-resolver-spi-1.6.2.jar
 36K ./60/0/.cp/jars/maven-resolver-transport-wagon-1.6.2.jar
168K ./60/0/.cp/jars/maven-resolver-util-1.6.2.jar
 44K ./60/0/.cp/jars/maven-settings-3.8.1.jar
 44K ./60/0/.cp/jars/maven-settings-builder-3.8.1.jar
164K ./60/0/.cp/jars/maven-shared-utils-3.2.1.jar
416K ./60/0/.cp/jars/okhttp-3.14.1.jar
 92K ./60/0/.cp/jars/okio-1.17.3.jar
372K ./60/0/.cp/jars/org.eclipse.sisu.inject-0.3.4.jar
204K ./60/0/.cp/jars/org.eclipse.sisu.plexus-0.3.4.jar
 12K ./60/0/.cp/jars/plexus-build-api-0.0.7.jar
 16K ./60/0/.cp/jars/plexus-cipher-1.7.jar
 52K ./60/0/.cp/jars/plexus-classworlds-2.6.0.jar
8.0K ./60/0/.cp/jars/plexus-component-annotations-2.1.0.jar
 84K ./60/0/.cp/jars/plexus-interpolation-1.25.jar
 28K ./60/0/.cp/jars/plexus-sec-dispatcher-1.4.jar
256K ./60/0/.cp/jars/plexus-utils-3.2.1.jar
 12K ./60/0/.cp/jars/wagon-file-3.4.3.jar
 56K ./60/0/.cp/jars/wagon-provider-api-3.4.3.jar
300K ./75/0/.cp/lib/snakeyaml-1.25.jar
360K ./77/0/.cp/lib/com.microsoft.java.debug.core-0.36.0.jar
320K ./77/0/.cp/lib/commons-io-2.11.0.jar
 12K ./77/0/.cp/lib/reactive-streams-1.0.3.jar
2.3M ./77/0/.cp/lib/rxjava-2.2.21.jar

They're grouped by plugin that embeds the jars.

77 (3.0MB) - com.microsoft.java.debug.plugin (extension to JDT-LS)
75 - com.redhat.microprofile.jdt.quarkus (extension to JDT-LS
60 (5.7MB) - org.eclipse.m2e.maven.runtime
59 (5.7MB) - org.eclipse.m2e.maven.indexer
54 (2.2MB) - org.eclipse.m2e.archetype.common
50 - org.eclipse.jdt.ls.core
49 - org.eclipse.jdt.launching
46 - org.eclipse.jdt.debug

Navigation Menu

Repository navigation

Support publishing pre-release versions #2285

Background

Channels

Publishing

Proposal

Versioning

Schema

Tips

Repository engineering

Branches

Management

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support publishing pre-release versions #2285

Description

Activity

CsCherrYY commented on Jan 19, 2022

Background

Channels

Publishing

Proposal

Versioning

Schema

Tips

Repository engineering

Branches

Management

rgrunber commented on Jan 19, 2022

CsCherrYY commented on Jan 24, 2022

CsCherrYY commented on Feb 10, 2022

CsCherrYY commented on Feb 16, 2022

CsCherrYY commented on Mar 18, 2022

rgrunber commented on May 12, 2022

CsCherrYY commented on May 13, 2022

Eskibear commented on May 13, 2022

rgrunber commented on May 13, 2022

CsCherrYY commented on May 16, 2022

rgrunber commented on May 16, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions