Versioning of specs

[cconcolato]

• Add a JSON mode for cw list
• Add spec version in JSON reports

[cconcolato]

The design principles regarding versioning are:

• CW only supports 1 version of a given spec, latest editions are considered backwards compatible, and if not it is the responsibility of spec editors to handle consequences
• We keep implementation of draft specs of new versions in a branch and merge when the spec is published
• we hope that sponsor/contributors for a given spec also sponsor/contributes updates to dependent specs

[bradh]

Another option would be to put the version into the spec. So if you want to update to ISO BMFF v8, the spec name would be isobmff_v8.

The reason for suggesting that is to ensure that newer capabilities aren't used by dependent formats e.g. if HEIF Ed 2 points to ISOBMFF Ed 7 (i.e. 2022), and it is not valid to use ISO BMFF Ed 8 (notional 2023+) capabilities in HEIF Ed 2.

[rbouqueau]

Any opinion on @bradh's remark?

[cconcolato]

The reason for suggesting that is to ensure that newer capabilities aren't used by dependent formats e.g. if HEIF Ed 2 points to ISOBMFF Ed 7 (i.e. 2022), and it is not valid to use ISO BMFF Ed 8 (notional 2023+) capabilities in HEIF Ed 2.

I think that is partially incorrect. HEIF refers to an undated version of ISOBMFF. So whatever changes are made in ISOBMFF, they are carried and valid in HEIF. I think this is generally the case for how specs refer to other specs. I understand that this can be a problem because implementations can then rarely be complete. To avoid that, a downstream specifcation can:
a) use a dated reference to an upstream specification. This has drawbacks. For example, if the upstream specification is corrected the corrections are not applicable. Another example is if a third downstream spec refers to these 2 specs but as undated versions. There is then ambiguity regarding the features of the base spec.
b) clearly define what features of the upstream specifications are supported. For example, for derived specifications based on ISOBMFF this means that a derived specification should indicate the exact boxes and versions that are supported (and typically define a brand for that). This is what CMAF and MIAF are trying to do. It might not be perfect, but it is preferred approach at the moment.

[bradh]

Concur. However there are cases where it does reference a dated version (e.g. ISO/IEC 15444-16:2021 references ISO/IEC 23008-12:2017, not 2022; and 23008-12:2017 references 14496-12:2015).

[rbouqueau]

I feel like this is quite clear, except for @bradh 's remark. Is anyone able to clarify?