Added OTIO_CORE 0.14.0 version_manifest. #1415
Conversation
jminor
force-pushed
the
downgrade_14
branch
from
ef88249 to
a0c6b48
Compare
Signed-off-by: Joshua Minor <[email protected]>
Signed-off-by: Joshua Minor <[email protected]>
Signed-off-by: Joshua Minor <[email protected]>
Signed-off-by: Joshua Minor <[email protected]>
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #1415 +/- ##
=======================================
Coverage 86.06% 86.06%
=======================================
Files 201 201
Lines 21062 21062
Branches 2461 2461
=======================================
Hits 18127 18127
Misses 2333 2333
Partials 602 602
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
jminor
force-pushed
the
downgrade_14
branch
from
a0c6b48 to
f535e3a
Compare
Signed-off-by: Joshua Minor <[email protected]>
| namespace opentimelineio { namespace OPENTIMELINEIO_VERSION { | ||
|
|
||
| const label_to_schema_version_map CORE_VERSION_MAP { | ||
| { "0.14.0", |
There was a problem hiding this comment.
Should we also have 0.14.1?
There was a problem hiding this comment.
Good question, @JeanChristopheMorinPerso. It would be identical to 0.14.0 right? Should we include every release from now on, or just add one when a schema changes?
There was a problem hiding this comment.
I'm under the impression we don't need 0.14.1 since it only contains bug fixes. But I prefer to ask just in case. Having all versions might make it easier for users to just say "write an OTIO file using that version" without knowing which version contained schema changes. But at the same time it's not like it's really difficult to get this map and figure out pretty quickly which version is required.
There was a problem hiding this comment.
Design notes:
- for this release, I think leaving it like this is fine, since we're backporting it anyway and don't have a strategy
- I think as a project we should have a discussion. There are two strategies that I can think of off the top of my head:
- we base everything off the library release version:
- every release gets an entry
- +: its straightforward, the only thing anyone needs to know is what version of the library you have
- -: (potential) we'll end up with a lot of entries that are the same
- -: (potential) we conflate software release with schema changes (less obvious when things are actually incompatible schema-wise
- we create a separate "schema version":
- +: Clear when things actually change
- +: might be more straightforward for nontechnical end users building pipelines
- -: adds another version number to track for folks, need to add tools for getting it and possibly recording it, etc.
- we base everything off the library release version:
) * Added OTIO_CORE 0.14.0 version_manifest. * Adding instructions for runtime downgrading to versioning-schemas.md * Removed Test schema from 0.14.0 version manifest. Signed-off-by: Joshua Minor <[email protected]> Signed-off-by: Michele Spina <[email protected]>
In order to ensure that users can downgrade to 0.14.0 easily, this PR adds a version_manifest entry for "0.14.0" which specifies the schema versions prior to the new Clip.2 multiple media reference feature #1241
In addition, this PR updates the documentation to clearly show how to use the downgrade system at runtime (either via environment variable, or via otioconvert).