Adopt to pre-release extension version support

[isidorn]

Hey @eamodio 👋

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 GitLens has a separate Insiders extension. Ideally you would adopt to our pre-release support and we would deprecate that other extension. VS Code can automatically migrate your existing GitLens Insiders users to the pre-release version of the extension once you have done the adoption.

Let me know what you think. Thanks!

[eamodio]

Hi @isidorn! I would love to adopt the new model, but I have a couple of questions:

How would current GitLens (Insiders) users get opt-ed into this new version? And maybe most importantly GitLens stores certain data in global and workspace storage (and some global keys are synchronized) how can that data be migrated from the old to new version? FYI, the valuable data is stored in workspace storage (the global values aren't personalized so don't matter)

[isidorn]

@eamodio great! Let me try to answer:

• You would ping us once this is ready. We have an internal migration table, we would add the old GitLens insiders extension to the table and once we detect that a user is running the outdated extension we would automatically migrate them to the GitLens extension and switch them to the insiders version. GitHub PR insiders on-boarded to this for example.
• We are not migrating any global or workspace storage at this moment. Would this be a problem for GitLens insiders - if yes can you provide an example bad user scenario? I am not sure if we want to support this in the future but I would just like to understand it better from your user's perspective.

@sandy081 can correct me if needed.

Related discussion microsoft/vscode-remote-repositories-github#91 (comment)

[sandy081]

Actually we are also thinking to migrate storage but the migration would be a simple replace and not merging. It means, if user has both gitlens and gitlens insiders installed, we will replace state of gitlens extension with gitlens insiders state.

[eamodio]

@isidorn to your question on storage:

GitLens stores a few things in global storage

• the current version — for version comparisons on upgrades to allow for data migrations and/or notifications
• a cache of fetched avatars
• state around whether you've seen a welcome or not

GitLens also stores some user preferences and personalization/usage data in workspace storage

• a flag for whether or not a workspace had repositories the last time it was opened (for performance optimizations)
• remembers the user's chosen comparison associated with each branch
• remembers any pinned (saved) comparisons and/or commit search queries in the Search & Compare view
• remembers favorite repositories
• remembers favorite branches
• remembers the user's chosen default remote — used to avoid having to pick a remote when using many of the remote commands
• remembers remote connections for rich integrations (e.g. GitHub issue/pr integration)
• remembers other misc state for some of the GitLens views

So losing that personalization/state would certainly not be desirable, but at the same time it would just cause aggravation, not "real" data loss.

@sandy081 Thanks, a couple of questions.

How would this work? For any storage migration would the user get to choose whether or not it happens?

I would want to avoid the case where a user had tried the insiders version of GitLens (e.g. to test a bug fix, etc) but would then have their possibly more important GitLens stable data overwritten by the insiders data.

I don't think just having both installed would be a good enough signal to overwrite the stable data with insiders -- enabled state IMO would need to be considered. But that gets more complicated for sure, as enabled state could be dependent on the workspace. And even enabled state might not be enough signal.

Here is what I would propose:

• User has GitLens installed — nothing to do here
• User has GitLens Insiders installed
  • copy/replace GitLens storage with GitLens Insiders storage
  • uninstall GitLens Insiders
  • install GitLens
  • switch to the insiders channel
• User has both GitLens and GitLens Insiders installed, with GitLens enabled (or both are enabled)
  • uninstall GitLens Insiders
• User has both GitLens and GitLens Insiders installed, with GitLens Insiders enabled
  • prompt the user to ask if they want to overwrite their GitLens data with their GitLens Insiders data
  • copy/replace the storage if requested
  • uninstall GitLens Insiders
  • install GitLens
  • switch to the insiders channel

Maybe in the last case, we could avoid prompting and just overwrite the data since it should be an edge/minority case (but since its destructive a prompt might be nice).

[sandy081]

I would prefer to migrate storage without any prompts as in most of the cases such a prompt is not helpful to decide and blocks migration.

[eamodio]

@sandy081 yeah, after going through it all, I think I agree that a prompt would just confuse more than help (and cause blocks as you mention). So with eliminating prompting, does the behavior of my proposed scenarios match what you are planning?

[isidorn]

@eamodio thanks for providing more details.

I also agree no prompts would be best in this case.
For reference here's the issue on the VS Code for migrating storage that we plan to look into this milestone microsoft/vscode#140088

[sandy081]

I will document the migration in the above issue Isidor mentioned.

[sandy081]

@eamodio Documented the migration in the linked issue - microsoft/vscode#140088. Please take a look

[eamodio]

@sandy081 I'm sure I'm missing something, but how does GitLens express that the storage should be migrated from GitLens (Insiders)?

I don't see how that gets expressed - that linked issue just has an embedder api.