Keep only latest (or next during development) version of a plug-in inside che-plugin-registry

[benoitf]

Is your task related to a problem? Please describe.

For now, a lot of plug-in versions are stored in the plug-in registry.
But for example all devfiles are using only latest version of plug-ins and we ensure that all plug-ins work on their respective runtime.

Describe the solution you'd like

Keep only the latest and optionally next version of the plug-ins of the components tied to lifecycle of Eclipse Che. (machine-exec and che-theia)

For example, there is no need to have che-theia:7.17.0 in the 7.20.0 plug-in registry as this version may not work on latest version of che. You may only want to try 'experimental'.
It would simply contributions to the plug-in registry and drop the 'deprecation policy' and maintainability.

Additional context

It's always possible to use custom plug-ins by adding a reference in the devfile.yaml so if someone really want a specific version and a specific runtime, it can be customized.

[ericwill]

👍 to this idea

[gorkem]

These plugins are referenced directly from devfiles with their versions, users should be able to go back to these versions however old they may be and should get a working workspace. If we are removing versions of plugins from registry we must also not allow devfiles to reference plugins with their versions but only with latest or similar meta tags.

[ericwill]

These plugins are referenced directly from devfiles with their versions, users should be able to go back to these versions however old they may be and should get a working workspace. If we are removing versions of plugins from registry we must also not allow devfiles to reference plugins with their versions but only with latest or similar meta tags.

All the devfiles in the registry are already using latest, at least based on a quick grep just now. So this shouldn't be an issue.

[gorkem]

How about devfiles on user repositories?

[ericwill]

They have a few options:

• Stay on the current version of the Che plugin registry they are using
• Upgrade to a later version, and reference the older plugin in a meta.yaml directly in the devfile
• Roll their own plugin registry if they are really interested in older plugins (for whatever reason)

[gorkem]

I do not think any of these options fit the use case. I have a project that I modify infrequently (once in a year perhaps) . I use Che so that I do not have to setup my developer environment. With this change now we are saying that you will have to setup your workspace.

[benoitf]

BTW even before this issue, all older plugins were removed after few sprints so I suppose your workspace contains only 'latest' version of plugin's so it should stil work perfectly fine

[gorkem]

We should not let devfiles to directly reference a version of the plugin and remove them? We are breaking the instance of the devfile. By allowing devfile to directly define a version of the plugin we are establishing a contract that the version of the plugin will be available. This is not very different from maven coordinate or versions on npm registry. Both maven and npm does not allow removal of published versions.

[benoitf]

npm and maven registries are global. Here, each Che instance has its own registry instance.
For airgap mode it's not possible to have image with all plugin's since the beginning.
Also vsix links may have been removed as it may be links to hosted files that are removed as registry do not host the files but just pointers by default

[ericwill]

We should not let devfiles to directly reference a version of the plugin and remove them? We are breaking the instance of the devfile. By allowing devfile to directly define a version of the plugin we are establishing a contract that the version of the plugin will be available.

No, we are making a contract that the version of the plugin will be available in the version of the Che plugin registry that was deployed when that devfile was written. The user is free to:

• stay on that version of Che,
• upgrade Che but use an older version of the plugin registry, or
• change their devfile (once) to point to a meta.yaml hosted elsewhere, should they really want that older plugin.

We are not obligated to support all devfiles in perpetuity. This isn't even the case right now as I have been removing old plugins after 3 sprints for the last ~8 months. So far no one has complained. In downstream we also only ship the latest version of a plugin.

In reality we cannot have the latest and greatest version of every plugin in our registry and also maintain a massive list of older plugins. Even with automation the maintenance burden is too high. It's easy for for VS Code and other IDEs to let users install/use any version of a plugin, because they don't need to maintain the dependency stack that goes with every extension.