Suggested Documentation change
We should introduce a Migration skill for Axon Framework.
This skill should provide users a guide rail to migrate from Axon Framework 4 to Axon / Axoniq Framework 5.
We should be able to base this skill of the numerous migration paths we have already build, as well as the api-changes.md file we maintained during construction of AF5 (to be found here). This should provide it a good base context to begin with.
Things the skill should cover are:
- Module changes
- Package/import changes
- Class renames
- Aggregate-to-Entity rewrite
- Test fixture rewrite
- Serializer-to-Converter usage
- Event Processor configuration changes
- Interceptor API changes
- Mark features/methods/classes as obsolete that won't return. When applicable, providing a work around (ideally from the docs).
- Mark features/methods/classes as planned for the future, when they're planned for the future. When applicable, providing a work around (ideally from the docs).
This skill should definitely clarify that we cannot eliminate that some manual steps are still required once it has done it's work!
With this basic skill in place, we should validate it against some of our sample projects, to see how it succeeds.
Lastly, we do not expect this to be a one-off. As time progresses, missers will be marked by users, as well as new features will find a replacement in AF5. We should adjust the skill accordingly when that occurs.
Suggested Documentation change
We should introduce a Migration skill for Axon Framework.
This skill should provide users a guide rail to migrate from Axon Framework 4 to Axon / Axoniq Framework 5.
We should be able to base this skill of the numerous migration paths we have already build, as well as the
api-changes.mdfile we maintained during construction of AF5 (to be found here). This should provide it a good base context to begin with.Things the skill should cover are:
This skill should definitely clarify that we cannot eliminate that some manual steps are still required once it has done it's work!
With this basic skill in place, we should validate it against some of our sample projects, to see how it succeeds.
Lastly, we do not expect this to be a one-off. As time progresses, missers will be marked by users, as well as new features will find a replacement in AF5. We should adjust the skill accordingly when that occurs.