Skip to end of metadata
Go to start of metadata

This is a work in progress document

We don't suggest or approve of deleting source code outright, even a stale or no-longer-relevant code can still be educational.

However, we do have a mechanism for hiding plugins in the update center that are dead, and we can update wiki pages for dead plugins accordingly.

Currently the suggest process for "deleting" a plugin is:

  1. Update the wiki page of the plugin with the plugin-deprecated label to the page (see Nabaztag Plugin) and add a warning of some form at the top of the page to let users know the status of the plugin (see also Nabaztag Plugin)
  2. In order to display the plugin only in the Deprecated plugins page and not in the available plugins page, remove labels other than plugin-deprecated from the wiki page of the plugin.
  3. Submit a pull request to the plugins README.md (or other file) indicating the status of the plugin on GitHub
  4. ??

If the plugin does not have a wiki page then it makes sense to create a wiki page if only for consistency with the steps above.


Another mechanism we have to exclude plugins from the update center is by updating artifact-ignores.properties to list the dead plugin's artifact ID. This shouldn't be necessary in almost all cases and is only mentioned here for completeness sake

See also Proposed Plugin Deprecation

  • No labels

1 Comment

  1. From repository viewpoint such ignores should be part of repository metadata. If you expose ignoredArtifacts into update-center.json it will be possible to provide ability for jenkins user undeprecate plugin by having some advanced options. 

    Obviously first point should be "Contact plugin maintainer, committers, PRs", wait for X months and only then delete something from end-user usages. Some users may not know that somebody on jenkins project side planning delete this plugin, so imho one of first steps can be have intermediate step with placing label `FutureIgnore` and only then do real filtering.