Problem/Motivation
This issue was originally created with the migration yml plugins in mind, it has been expanded to include all plugins. See #39.
Migrations are plugins and plugins are covered by the core BC policies, specifically :
Particular plugins, whether class based or yaml based, should not be considered part of the public API. References to plugin IDs and settings in default configuration can be relied upon however.
This means that in order to remove migration ymls from core, we must first deprecate them, and then remove them in the next major version. We currently have no means of marking migration ymls as deprecated nor triggering a deprecation error if they are used. This came up for the first time in #3022401: Remove useless config action.settings.recursion_limit where it was determined that the action_settings migration was no longer needed. The migration was set to a null destination to render it useless but there is currently no mechanism to declare it deprecated and scheduled for removal in Drupal 9.
We are now faced with the prospect of deprecating all the Drupal 6 migration for removal to a contrib project, and we have no means of marking them for removal in D9 either.
Proposed resolution
Add a Trait for checking the deprecation status of a plugin.
Indicate deprecation by the property 'deprecation_message' for a plugin defined by an array or 'deprecationMessage' for a plugin with an object definition. Adding a plugin flag was considered but was deemed redundant, the presence or absence of the message is sufficient.
Make it so other plugin systems in contrib can use this to deprecate as well.
Remaining tasks
Identify a list of relevant places that all need to be updated and create follow-up issues for that.
User interface changes
none
API changes
A means to declare a migration as deprecated and trigger an error will be added
Data model changes
None
Release notes snippet
Core migrations can now declare themselves deprecated