You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When looking into ways to manage a bad deployment of an extension, we've investigated what options are currently available with this wonderful extension.
Something that would make our job easier is if the extension would prompt the user to downgrade their version if the channel that they are tracking does not match their current version.
For example:
A user has installed [email protected] (and 1.0.0 is tagged as latest) and everything is great
The extension maintainers push out [email protected] and add so many bugs that the extension is unusable. As part of the deployment, 1.1.0 is tagged as latest. Let's ignore that hopefully a competent testing model would catch bugs before they go out.
If the 'latest' tag is reapplied to 1.0.0 to avoid the 'bad' 1.1.0 deployment, users will not be prompted to change their installed version.
A potential enhancement would be to change the process of changing an extension's installed version, so that in the above example, any users who managed to upgrade to 1.1.0 would be again prompted to change back to 1.0.0.
Instead of always looking to make the version number go up, users would be prompted to upgrade whenever their installed version doesn't match the tracked version.
A quick glance at the code points to this method in Package.ts needing changes for this feature.
public get isUpdateAvailable(): boolean {
return !!this.installedVersion && this.version > this.installedVersion;
}
I haven't taken a stab at implementing the change myself yet but wanted to see if this was something you considered and explicitly decided not to do, first.
The text was updated successfully, but these errors were encountered:
This is not something I had considered. If these bad deployments are uncommon, maybe you could just republish the last good version with a newer version than the bad version instead?
If they are common, it does seem like it could be a useful feature, though I think it could get annoying when you're developing a new version of an extension and haven't published it yet. I don't think we should treat it as an upgrade though. If the extension manager is going to ask users to downgrade an extension because what they have is newer than what is in the registry, then I think it should inform users that it will be a downgrade.
Yea republishing with a higher version number is also an option without any extension changes. This suggestion is to build out the functionality of the extension so that it's a bit more flexible with how it treats tracked versions. I agree it could be annoying when doing active development to keep getting nudges about not being up to date with the tracked version, but I'm more focused on the users who just want things to work and get nudged appropriately.
I'll keep your feedback in mind, I agree that being prompted to "upgrade" for a downgrade would also be confusing.
When looking into ways to manage a bad deployment of an extension, we've investigated what options are currently available with this wonderful extension.
Something that would make our job easier is if the extension would prompt the user to downgrade their version if the channel that they are tracking does not match their current version.
For example:
A potential enhancement would be to change the process of changing an extension's installed version, so that in the above example, any users who managed to upgrade to 1.1.0 would be again prompted to change back to 1.0.0.
Instead of always looking to make the version number go up, users would be prompted to upgrade whenever their installed version doesn't match the tracked version.
A quick glance at the code points to this method in Package.ts needing changes for this feature.
I haven't taken a stab at implementing the change myself yet but wanted to see if this was something you considered and explicitly decided not to do, first.
The text was updated successfully, but these errors were encountered: