Trait/Specification versioning

[foundrytom]

What

Define and implement the mechanism by which we can manage changes to trait/specification definitions (crud on properties, changing trait sets, etc...)

Why

The schemas applied to TraitsData are really the main API contract for managers/hosts as it is potentially persisted either side of the boundary. We have to make sure we have a robust change management process, both in terms of technical mechanisms and agreed process.

Tasks

• [Investigation] Trait/Specification versioning strategies #73
• Decide on In-Data vs Out-of-Data versioning #83
• Spike to sketch out what in data per trait versioning looks like #88
• Consider recommending vendoring MediaCreation #61
• Versioning generation behaviour. OpenAssetIO-TraitGen#80
• Update schema to be compatible with trait versioning #98

[antirotor]

Related to this - I think we'll need to introduce something like trait version. At least from the beginning the Traits will be in a fluid state and changes will be made and until it settles down the need for some kind of versioning will be great. For example you'll have Trait Geometry and after while you'll find that it is missing let's say upAxis. Introducing new property will not break backwards compatibility, but for renaming will so I guess something like semantic versioning will help to solve that?

[foundrytom]

Yes 100%. Our plan is currently:

• Get the core API stable (as we established this shouldn't be affected by schema versioning), should be done "soon".
• Figure all this out.

We hadn't put too much effort into it just yet as we were hoping more people like your good self would be on the scene when we did, so we can try and make sure the solution is a good one!

We've started #api-data-schemas to try and get together with the OTIO and USD people (and anyone else), who has exactly the same challenge. We really didn't want to re-invent this particular wheel in OpenAssetIO. I hope we can build on the solutions they are using to this problem.

[elliotcmorris]

The work going on here will possibly/probably make #61 redundant.