Problem/Motivation
Other modules need a way to declare their migration status and thus control which list (available upgrade path or missing upgrade path) they will appear in on the Migrate Upgrade review page, /upgrade.
The form lists all modules on the source site in either a 'missing an upgrade path' or 'available upgrade path' list. If the module has migrations it will be displayed in the 'available upgrade path' list, even if it only has one migration and needs more than one to be complete. If it as no migrations it will be displayed in the 'missing an upgrade path list', even it does not need an upgrade path. This will lead to misleading data for the user.
In a migrate meeting, using a hook or an event was discussed. A possible solution, using hook_form_alter, was implemented in #2914974: Migrate UI - handle sources that do not need an upgrade and removed after a review #176. That review asked some questions, listed below, which should be resolved here.
- The CR is titled Provide a Method to Intentionally Mark Modules, Themes and Profiles as not Upgradable but we're not really providing a method.
- Did we give consideration to a dedicated API? E.g. we could put entries in .info.yml or we could put .migrate.info.yml files in modules.
- How likely is it that contrib modules will need to make this change?
Note: As of this writing, there is the two categories of 'missing' and 'available'. Another category, 'incomplete' is being added, #2928147: Migrate UI - add 'incomplete' migration status
Proposed resolution
In a migrate meeting option #2 was decided as the best option, reasons included that it is easy to add and there is no need to write code. See #7 and #8.
Add a version key to identify the source version. While working on this it became clear that the status needs to be declared by source version. See #10
Remaining tasks
- Decide on the format of the new 'migrate' key and values in .info.yml. Suggested formats are in #11 and #15. Currently proposed format is the one presented in #11.
- Decide on the allowed values for status. Suggestions are in #7, #9. Currently proposed values are 'complete', 'incomplete' and 'n/a'
Decide if adding a key for source version is ok.As pointed out in #10, the status needs to be declared by source version.- Review
- Update change record
- Update handbook documentation
- Commit