Some plugins may be replaced by others or just become irrelevant (e.g. integration with a service which was shut down). We do not recommend deleting source code outright, even a stale or no-longer-relevant code can still be educational. However, we do have a mechanism for deprecating or hiding plugins in the Jenkins update centers. This page describes the processes for marking a plugin as deprecated or suspending its distribution entirely.
Set a deprecated label for the plugin that will be visible on plugins.jenkins.io and in the Jenkins plugin manager. This can be done in two ways:
Put a deprecated topic in the plugin’s GitHub repository.
If you have multiple plugins inside a single repository, it will apply to all of them.
This is the preferred approach.
Add a deprecated label to the plugin entry in the Update Center’s label-definitions.properties file.
Choose this approach if the GitHub repository contains multiple plugins and only some of the plugins in the repository are to be deprecated.
Update the plugin’s documentation to explain the reason of the deprecation.
Submit a pull request to the Update Center’s artifact-ignores.properties file. Use the artifact ID as key. As value, provide a URL to a web page (usually documentation) that explains to users why distribution is suspended. Specifying a URL will also cause a deprecation message to appear.
Archive the plugin’s GitHub repository.
If you have admin permissions in the repository, it is possible to do it from the GitHub’s web interface.
Otherwise, create a help desk ticket to archive the plugin’s repository.
If required, it is possible to revert all the actions above. A helpdesk ticket is required to unarchive a plugin, but the rest can be done via pull requests to the respective update center files mentioned above.