Support publishing pre-release versions

[testforstephen]

• 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

[CsCherrYY]

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

[rgrunber]

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]

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

Yeah, this might cause merge conflicts since we are committing into master and insider at the same time. An alternative way is

• All new commitments will be merged into insider
• when we want to release a new stable version, we cherry pick those commitments from insider into master manually

Actually, this way we will still encounter those conflicts between experimental commitments and common commitments, but we can avoid

changes from stable may fail the auto cherry-pick into insider

[CsCherrYY]

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]

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.

[CsCherrYY]

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?

[rgrunber]

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

[CsCherrYY]

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

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.