Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support publishing pre-release versions #2285

Closed
testforstephen opened this issue Jan 14, 2022 · 12 comments · Fixed by #2371
Closed

Support publishing pre-release versions #2285

testforstephen opened this issue Jan 14, 2022 · 12 comments · Fixed by #2371

Comments

@testforstephen
Copy link
Collaborator

@CsCherrYY
Copy link
Contributor

CsCherrYY commented Jan 19, 2022

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
    image
  • for VS Code stable users, the default channel is stable channel
    image
  • 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

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
image

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

@rgrunber
Copy link
Member

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

@CsCherrYY

This comment was marked as outdated.

@CsCherrYY
Copy link
Contributor

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.

@CsCherrYY
Copy link
Contributor

CsCherrYY commented Feb 16, 2022

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

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

and the stable version is recommended in vscode stable
image

after installed, you can also switch to the other channel
image

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.

@CsCherrYY
Copy link
Contributor

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

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?

@rgrunber
Copy link
Member

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

vscode_java_prerelease

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

@CsCherrYY
Copy link
Contributor

CsCherrYY commented May 13, 2022

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

@Eskibear
Copy link
Contributor

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.

@rgrunber
Copy link
Member

rgrunber commented May 13, 2022

We could always add the logic to

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

@CsCherrYY
Copy link
Contributor

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?

@rgrunber
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants