Option to auto-update extensions based on semver

[heaths]

As an extension author, I'd like to make some breaking changes to my extension. As a user, I'd hate to have an extension automatically updated with breaking changes.

What would be nice is an option in VSCode to only auto-update minor or patch versions (or maybe even patch versions, or completely disable) of extensions and show updates (for manual update) for major versions with some workflow to show the changelog of breaking changes (if the developer authored any).

For example, extensions.autoUpdate could be changed from a boolean to an enumeration with backward compatibility to a boolean. I seem to recall another similar change but it was long ago enough I don't remember. IIRC, there is precedence to change the type.

I didn't see any request like this already, though a possible implementation might overlap with #30579 if auto-update for installed prerelease versions could be disabled entirely.

[sean-mcmanus]

If this occurs, I'd prefer an exception for 0.x.x to 1.0.0 upgrades, which may only signify an extension becoming "feature complete" and exiting preview mode and not being incompatible with previous versions. Adding something like a "fromVersion" to mimic the npm package versioning might be better, e.g. adding "fromVersion" 1.2 would mean someone with 1.1.x or lower wouldn't get an automatic upgrade.

[sandy081]

Duplicates #15756

[heaths]

While related, that is not a duplicate. I'm not talking about duplicates. @sean-mcmanus brought that up. My OP is about not automatically upgrading to a version with breaking changes, in my case from v2->v3 (planned). There may be some overlap in how these two things are implemented, but both bugs should remain open to make sure both scenarios are accounted for and tested.

[sandy081]

@heaths I see both requirements need a beta version support for extensions so that authors can publish and let users try it out. Currently you can distribute the vsix for the users to try out.

[sandy081]

@heaths I see what you mean.. Let me reopen it and track them separately.

[heaths]

Besides, I'd be interested I discussing how to implement this here (feature design) and maybe even implementing it. At least from the issue I linked, there's mention of how npm solves this so maybe we allow for users to author a new setting using npm-style version ranges, like "^2.0" if we wanted to make it extension-specific. Frankly, I'd prefer a global mechanism since I wouldn't want any extension that is (if properly implementing semver) introducing breaking changes without first reviewing them, hence my suggestion of supporting either a boolean for the existing setting or a new enum.

[sandy081]

We came up with a proposal to support beta exetensions here - #15756 (comment) and the proposal also takes care of this scenario - users opted to insiders/preview of an extensions will get latest and cutting edge changes whereas who does not will get stable and non breaking changes. Other than this we would like to not support any additional configuration to configure updates by semver. Hence closing this as out of scope.