We need to define on a plugin deprecation policy

Is your task related to a problem? Please describe.

Plugins in the registry support a field

deprecate:
  automigrate: true/false
  migrateTo: <new plugin ID>

however, there is no defined policy on when this property should be used, and it’s thus left up to whoever opens the PR to update a particular plugin. A consideration here is that there are two ways of specifying which plugin you want in your workspace:

1. Use latest (the default): you’re only affected by deprecate when one plugin is deprecated in favor of another plugin; the use of deprecate is clear here.
2. You forego latest and explicitly set a plugin version in your meta.yaml. Currently, there’s not much reason to do this, but we offer it as an option, so we need to consider it.

Options

In increasing order of “how often deprecate is used”:

1. Deprecate when a plugin explicitly should no longer be used

We deprecate plugins when we don’t think users should use them, even if they chose that version specifically. Examples include

• Security vulnerability is found in an old plugin
• We want to remove the plugin from the registry since it’s a year old or from a pre-release version
• We want to change the publisher or name of a plugin (e.g. moving from camel-tooling/vscode-apache-camel to redhat/vscode-apache-camel)

Pros:

• Almost no chance of incompatability

Cons:

• Highest requirement in terms of maintaining plugins (basically have to keep every plugin release, forever)

2. Deprecate old versions of plugins

We deprecate plugins when their version is outdated by some metric. For example we could deprecate plugins within major semver versions:

• If 1.2.0 is released, deprecate all 1.1.x releases.
• If 2.0.0 is released, keep latest 1.x.y version.

Pros:

• Provided semantic versioning is used as intended, this supports a common-sense use of the registry (“I want the latest release in major version 1.x”)

Cons:

• Some maintenance / manual work required when releasing a new version of a plugin.

3. Deprecate all older versions

When a new plugin is released, the previous version is deprecated.

Pros:

• Simplest option, allows trimming number of supported plugin releases in registry (3mo after a plugin is deprecated, we could remove it)

Cons:

• Makes the option of choosing any version other than latest meaningless.
• A plugin removing a feature means users cannot choose the older version.

Historically, we’ve used option 1, and the registry supports creating a workspace with che-theia version 7.0.0-rc-4.0 (which IMO is an argument against it).

cc: @l0rd @slemeur @nickboldt

[ericwill]

To clarify, the policy I am following (which seems to be working) is:

• 3 versions of a plugin at any time
• Deprecation of the oldest plugin happens when a 4th plugin is added
• Deprecated plugins are removed after 3 sprints

[l0rd]

I am not sure I understand the autoMigrate use case.

My reasoning was based on the fact that the default version of a plugin is latest. Hence plugins gets “potentially” updated at every restart of a workspace. In other words deprecating and removing older versions of plugins has a minimal impact on users whereas maintaining multiple versions, migration mechanisms etc…is complicated and takes time to maintain.

I would not enable/implement the auto-migrate mechanism. I would rather:

• in the case of a deprecated plugin version: warn users when while a workspace including such a is starting
• in the case of a removed plugin version: provide a message explaining the problem and how to address it without even try to start the workspace