Backwards and forwards compatibility

Currently OTIO can read old .otio files that were serialized with older schema versions, because there is a built-in schema upgrade system. However, if an .otio file is written with a brand new schema revision, then software linked with an older version of OTIO will not be able to read those files. If you attempt this, a SCHEMA_VERSION_UNSUPPORTED error occurs.

In a one-way pipeline, this is manageable, as long as you are careful to upgrade the OTIO version in your software starting with the most downstream end of the pipeline, working your way back to the start. For example a pipeline which passes .otio files from: A to B to C is upgraded C, then B, then A.

However, one of OTIO’s stated goals is to support round-trip pipelines. Even if a pipeline is only two pieces of software, A and B, they must be upgraded in lock step anytime a OTIO schema version change is introduced.

To solve this problem, we must do one of the following:

• Allow modern OTIO software to write out old OTIO schema (controlled by a configuration option).
• Allow old OTIO software to read modern OTIO schema (via some runtime plugin).
• Modify our strategy for schema changes to ensure that revisions can still be read by old software (within some range of versions).
• Never change the schema.

Are there other options? Can we look at other file formats for inspiration or guidance on this?

[JeanChristopheMorinPerso]

@ssteinbach in case you want this issue to be closed when your PR gets merged, you have to link the other way around. In the sense that it’s in your PR description that you need to mark your PR as closing this issue, see https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue.

[ssteinbach]

Closed by #1387