Deprecate old plugins from plugin registry and remove after 3 sprints

[nickboldt]

Is your task related to a problem? Please describe.

We have ancient plugins in from before Che 7.0.

We also have plugins that predate CRW 2.0 / Che 7.3.3, which we're never going to go back and patch.

And we have plugins from 3 sprints ago that are effectively also at EOL since the only way they'll be fixed is to move to the latest 7.newer release.

So if 7.4, 7.5, 7.6, 7.7, 7.8 are never going to get maintenance support, why not remove them so we can focus on 7.9.x (LTS, CRW 2.1) and 7.3.3 (previous LTS, CRW 2.0) and the newer releases?

Describe the solution you'd like

Deprecation policy for plugins in plugin registry is:

We agree that we are going to deprecate plugin X
We remove any reference to plugin X in the devfile registry => sprint Y
We remove the plugin from the plugin-registry => sprint Y+3

(per #15327 (comment) )

Thus I'd like to remove all old che-machine-exec and che-theia* plugins, keeping only 7.3.3, 7.9.1, 7.9.2, 7.10.0 and future:

    docker.io/eclipse/che-machine-exec:7.0.0
    docker.io/eclipse/che-machine-exec:7.1.0
    quay.io/eclipse/che-machine-exec:7.2.0
    quay.io/eclipse/che-machine-exec:7.3.0
    quay.io/eclipse/che-machine-exec:7.3.1
    quay.io/eclipse/che-machine-exec:7.3.2
    quay.io/eclipse/che-machine-exec:7.4.0
    quay.io/eclipse/che-machine-exec:7.5.0
    quay.io/eclipse/che-machine-exec:7.5.1
    quay.io/eclipse/che-machine-exec:7.6.0
    quay.io/eclipse/che-machine-exec:7.7.0
    quay.io/eclipse/che-machine-exec:7.7.1
    quay.io/eclipse/che-machine-exec:7.8.0

    docker.io/eclipse/che-theia:7.0.0
    docker.io/eclipse/che-theia:7.0.0-next
    docker.io/eclipse/che-theia:7.0.0-rc-3.0
    docker.io/eclipse/che-theia:7.0.0-rc-4.0
    docker.io/eclipse/che-theia:7.1.0
    docker.io/eclipse/che-theia:7.2.0
    docker.io/eclipse/che-theia:7.3.0
    docker.io/eclipse/che-theia:7.3.1
    docker.io/eclipse/che-theia:7.3.2
    docker.io/eclipse/che-theia:7.4.0
    docker.io/eclipse/che-theia:7.5.0
    docker.io/eclipse/che-theia:7.5.1
    quay.io/eclipse/che-theia:7.6.0
    quay.io/eclipse/che-theia:7.7.0
    quay.io/eclipse/che-theia:7.7.1
    quay.io/eclipse/che-theia:7.8.0
    quay.io/eclipse/che-theia:7.9.0

    docker.io/eclipse/che-theia-endpoint-runtime-binary:7.3.1
    docker.io/eclipse/che-theia-endpoint-runtime-binary:7.3.2
    docker.io/eclipse/che-theia-endpoint-runtime-binary:7.4.0
    docker.io/eclipse/che-theia-endpoint-runtime-binary:7.5.0
    docker.io/eclipse/che-theia-endpoint-runtime-binary:7.5.1
    quay.io/eclipse/che-theia-endpoint-runtime-binary:7.6.0
    quay.io/eclipse/che-theia-endpoint-runtime-binary:7.7.0
    quay.io/eclipse/che-theia-endpoint-runtime-binary:7.7.1
    quay.io/eclipse/che-theia-endpoint-runtime-binary:7.8.0
    quay.io/eclipse/che-theia-endpoint-runtime-binary:7.9.0

I would further suggest we deprecate these, and remove them after 4 sprints.

    quay.io/eclipse/che-sidecar-dependency-analytics:0.0.12-d478351

    quay.io/eclipse/che-sidecar-kubernetes-tooling:0.1.17-51a0085
    quay.io/eclipse/che-sidecar-kubernetes-tooling:1.0.0-58ad4e2
    quay.io/eclipse/che-sidecar-kubernetes-tooling:1.0.4-a46d022

    quay.io/eclipse/che-sidecar-openshift-connector:0.0.17-eec0eef
    quay.io/eclipse/che-sidecar-openshift-connector:0.0.21-b582160
    quay.io/eclipse/che-sidecar-openshift-connector:0.1.0-5460589
    quay.io/eclipse/che-sidecar-openshift-connector:0.1.1-9ab314d

    quay.io/eclipse/che-sidecar-camelk:0.0.9-9e8538e
    quay.io/eclipse/che-sidecar-camelk:0.0.10-70f9d17
    quay.io/eclipse/che-sidecar-camelk:0.0.10-d5989b6
    quay.io/eclipse/che-sidecar-camelk:0.0.11-01afea6

Describe alternatives you've considered

Never throwing out the trash. Waiting for the mountain of garbage to crush us. :D

Additional context

Use digests instead of tags to reference images 16047

#15327 (comment)

[apupier]

How can we check the version that are used in CodeReady Workspaces?

[tsmaeder]

The assumption underlying this proposal is that we ship a version of the plugin registry with every version of Che. But if we ever get to a state where we actually have a plugin registry that is external, we'll have to support older versions of Che.
The "right thing", IMO is to introduce a description of which plugins work with which Che version. That would also resolve the issues where we deploy the wrong version of the registry.

[nickboldt]

couple thoughts...

• the supported list is the one we ship with Che (or CRW). Externally built registries are not our problem, they're supported by whoever build it.
• having Yet Another Level Of Metadata when you already have the plugin registry code in GH seems needless to me. Want to know which plugins were in CRW 2.1.1? Here's the list:

https://github.com/redhat-developer/codeready-workspaces/tree/2.1.1.GA/dependencies/che-plugin-registry/v3/plugins

Want the list in Che 7.14.3? Here's that list:

https://github.com/eclipse/che-plugin-registry/tree/7.14.3/v3/plugins

Bottom line:

Keeping old garbage versions around because Some Day We Might Need Them (?) is not a good way to stay agile. Out with the old, in with the new.

[nickboldt]

This might be a dupe of work you're already doing @ericwill .

See also #17562

[ericwill]

The deprecation + removal of plugins is something we can automate too. It can (loosely) be two-fold:

• A nightly job that opens a PR deprecating any plugin where there are already three newer plugins
• A nightly job that opens a PR to remove plugins that have been deprecated for more than 9 weeks (3 sprints)

[nickboldt]

Slip to next sprint. Is automation still on the radar?

[ericwill]

Slip to next sprint. Is automation still on the radar?

Yes, but not for next sprint. I'd say this is a 7.x task.

[ericwill]

We only keep the latest plugins now, so this one is dunzo