Adopt the pre-release extension version

[isidorn]

Hi VS Code PM here 👋

Refs: microsoft/vscode#15756

VS Code now supports pre-release extensions. Docs that should help: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions

I know IntelliCode has a separate IntelliCode insiders extension. Ideally IntelliCode would adopt to our pre-release support and we would deprecate that extension. VS Code can automatically migrate your existing IntelliCode insiders users to the pre-release version of the IntelliCode extension once you have done the adoption.

Let me know what you think

[ayim]

@isidorn Happy New Year! Sorry for the delay with getting back to ya here.

Reading through the docs right now.. have a question:

Background Info: We do indeed have three extensions right now: the general extension, insiders (which has experimental features), and a dogfood extension. The first two are public right now, and as you've noticed, we do have a third internal extension that is currently using the line completions API. Seems like this conversation is about moving the latter to the pre-release mechanism.

The IntelliCode insiders extension has functionality that is highly experimental and might never make it into the general extension

Question: Would we have the ability to restrict installation of pre-release versions to say, users on a certain domain?
The nature of AI products means that we often require fairly extensive internal testing before we release to public preview

[isidorn]

@Aiym Happy New Year to you too! No problem with the delay.
This conversation is about moving the insiders one to pre-release, so the one that is public.

Currently we do not have support to restrict installation of a particular extension to some domains.
We have heard similar requests for "hidden" extensions already. Here's an issue that is tracking that microsoft/vsmarketplace#292
However I think we will not have that in the near future.

[vivlimmsft]

One challenge with this is that there is no overlap between our main extension and the insiders extension - they each provide a different set of features. Changing to the pre-release model would require us to produce a pre-release extension which contains both the functionality of the main extension and the current insiders extension, which is not out of the question but we should have a clear reason if we do the migration -- it does seem that it would complicate things for us somewhat.

If extension authors do not want their pre-release users to be updated to the release version, we recommend to always increment and publish a new pre-release version before publishing a release version in order to make sure that the pre-release version is always higher.

In particular this seems like it would be a pain point as we would need to always publish two extension updates at a time- one with any updates to core features, and one containing the insiders ring's features as well as updates to the core features.

[isidorn]

@vivlimmsft that's fair. If you think that having two parallel extensions since they are so different is a better fit then that might be the way to go.

I created this issue that you consider using the pre-release support. Since I think in the end it would be a better experience for the users.

[ayim]

In general, I think the pre-release support is an improvement for most extensions - we just have a very niche use case/strategy for how we split things.

Added a comment to #292, this would help us move our third extension (the one currently consuming line completions API) into Marketplace.

[tjx666]

It's strange that stable version update date late that insider version 😳

[ayim]

@tjx666 the stable and insider extensions have different goals - one contains AI assisted development tools that we think is ready for consumers. The other contains experiments that we might not end up shipping at all