-
Notifications
You must be signed in to change notification settings - Fork 414
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
Comments
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. BackgroundChannels
Publishing
ProposalVersioningSchema
Tips
Repository engineeringHere 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
Management
|
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). |
This comment was marked as outdated.
This comment was marked as outdated.
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 |
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 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 :
|
@rgrunber Great! As for the storage issues:
|
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 Line 999 in 72633ab
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 |
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 :
They're grouped by plugin that embeds the jars. 77 (3.0MB) - com.microsoft.java.debug.plugin (extension to JDT-LS) |
The text was updated successfully, but these errors were encountered: