Posted by chx on October 29, 2013 at 5:41pm
We need to version the sources for sure. I can't remember a case when a core minor release would break our queries but such things definitely happened in contrib (look at CCK it keeps the table names in a function because of this).
And then we need other to handle other requirements as well. To me it feels every plugin needs to have a say (think of it, source, process and destination for sure needs it), so add a MigrationRequirementsInterface and let the plugins optionally implement it? Would we let the plugins call system_get_info directly? Careful there, it calls system_rebuild_module_data so if we have a ton of plugins calling that then starting a major version migration will take forever so it needs some wrapper somewhere.
Comments
The mentioned interface
The mentioned interface sounds like a good idea, then it is easy to ask if the object implements the interface before calling the method.
Please also notice that this will solve the problem for destination and process plugins, and partly for sources(getting information on the destination system).
The missing bit for the sources will be about retrieving general data from the origin place(origin system), in the case of sql sources, we would also like to know i.e. module status, module schema, etc.
This last kind of interaction is modeled in migrate_d2d adding a DrupalVersion object inside migrations.
We can do the same and share the information on migration, but in order to make it generic enough, we will probably will need to use an intermediary migration class like MigrationFromDrupal.
I would say that most of the data about origin system will be needed by sources, so I would propose to add DrupalSource/DrupalSqlSource/Drupal6SqlSource/Drupal7SqlSource(analogous to migrate_d2d DrupalVersion and related) classes to make them serve as base classes for real sources.