Problem/Motivation
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
Determine and document a means of declaring a migration yml as deprecated. This could be as simple as defining a "Deprecate migration tag, or we could declare and document a new optional key in migration ymls containing additional information regarding which version the migration was deprecated, and in which version it will be removed, along with any reasoning or alternatives to use in its place.
Finally we should find an appropriate place and way to trigger an error if the deprecated migration is ran. We should be careful to not trigger this error during discovery, but only if the migration is actually ran or rolled back
Remaining tasks
- Add tests
- Add an implementation of this for action plugins
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