Problem
The original release (v0.1.x) of ApodiniMigrator included support for migration guide providers to annotate addition, removal and idChange (identifier renames) with so called ProviderSupport objects. Those could be used to resolve uncaught type renames or wrongly classified type renames.
With the rewrite happening in v0.2.0, the feature wasn't reimplemented, as of now. This issue tracks reimplementing this feature.
Solution
As the newly introduced change model enforces the structure of a specific change, one can reimplement this feature with distinct typed versions for addition, removal and idChange cases of the Change enum. Therefore, this can be implemented for any change element.
Additionally, one need to implement a resolving step (ideally in the DocumentComparator) which actually interprets the provided renaming hints, such that a Migrator won't need to manually do that.
Additional context
#6
Code of Conduct
Problem
The original release (v0.1.x) of
ApodiniMigratorincluded support for migration guide providers to annotateaddition,removalandidChange(identifier renames) with so calledProviderSupportobjects. Those could be used to resolve uncaught type renames or wrongly classified type renames.With the rewrite happening in v0.2.0, the feature wasn't reimplemented, as of now. This issue tracks reimplementing this feature.
Solution
As the newly introduced change model enforces the structure of a specific change, one can reimplement this feature with distinct typed versions for
addition,removalandidChangecases of theChangeenum. Therefore, this can be implemented for any change element.Additionally, one need to implement a resolving step (ideally in the
DocumentComparator) which actually interprets the provided renaming hints, such that a Migrator won't need to manually do that.Additional context
#6
Code of Conduct