Streamline migration from v2/v3 to v4

maxime-rainville commented 4 months ago

As a developer maintaining a project using LinkField v2/v3, I have a a clear path and clear guidance on how to migrate to v4.

Acceptance criteria

[x] A BuildTask exists to converts LinkField v2/v3 data to v4 format.
- [x] The task accounts for versioning and all pre-existing links are assumed to be published.
- [x] Task accounts for HasMany relations to Link
- [x] Task can be extended to accommodate unusual usage of LinkField.
~~Deprecation warnings are added to v3.~~ see https://github.com/silverstripe/silverstripe-linkfield/issues/246
[x] Clear guidance on how to migrate to v4 is provided
[x] Guidance covers the scenario where a project is upgraded all the way from CMS 4.
[ ] Guidance covers how to migrate custom link types.
[x] Guidance mentions that we are assuming no versioning of v2/v3 links
[x] Migration task is marked as @deprecated.
[x] The task is disabled by default.

Exclude

Migration of DBLink data.

Possible unusual v3 customisations

Versioned links in V3
Custom links types
Link data with Fluent

PRs

See this installer run for green CI with the combined PRs.

GuySartorelli commented 4 months ago

Should the task be enabled or disabled by default? I'd recommend disabled by default so it's not present for new installations. Developers who are migrating can enable it with a simple yaml config, run it, and disable it again afterward.

Bear in mind this is one of three migration tasks, and only one of these will apply to any given project, so probably makes sense to not show them all by default.

maxime-rainville commented 4 months ago

My assumption was be that this task would a dev/build task. You would have to explicitly choose to run the task by calling it. This would seem to negate the need to have the option to enable/disable it.

Did you have something else in mind?

silverstripe / silverstripe-linkfield