Consider the hardwiring of `cff-version` values in the schema

[sdruskat]

Reported by @hainesr via email:

We’ve hardwired the 1.3.0 spec to only validate “cff-version” as 1.3.0. I think we should allow 1.3.0 to validate cff-version 1.2.0 if we are aiming for backwards compatibility. But I’m not sure! My, perhaps flawed, thinking is that if we can’t validate a 1.2.0 CFF file with the 1.3.0 schema then it’s not backwards compatible, so we have to go to 2.0.0.

[sdruskat]

1. Yes, we should hardwire the identifier to maintain machine-readability. We chose to communicate to machine users the schema they will have to use to validate a file.
2. For the identifier, we chose SemVer to communicate to human users what kind of potential breakage to expect, and the addition of new features.
3. We agree with your assessment, @hainesr, that at least ideally you should be able to validate a file with a schema >= cff-version in the file: a 1.2.0 file should be valid against the 1.3.0 schema. The only exception is cff-version.

For tooling this means that you should be able to use the latest version of the schema for validation. To deal with the cff-version error that may come up, you can either ignore that, or change the data before validation (i.e., increment cff-version to whatever schema >= file value you are using.

[hainesr]

There's not an easy solution to this.

If we suggest that tooling ignores the cff-version error then one could have a CFF file with 1.3.0-only features in it, but a cff-version: 1.2.0 and it would pass - which feels completely wrong.

I think perhaps it's fine to just say something like, "Yes, 1.3.0 is backwards compatible with 1.2.0, but you still need to validate against the correct version of the schema."

[sdruskat]

There's not an easy solution to this.

Agree.

If we suggest that tooling ignores the cff-version error then one could have a CFF file with 1.3.0-only features in it, but a cff-version: 1.2.0 and it would pass - which feels completely wrong.

Good point. FWIW, @jspaaks was suggesting that tooling could introduce an argument --validate-as which takes a schema version, so that this behaviour would be made explicit.

I think perhaps it's fine to just say something like, "Yes, 1.3.0 is backwards compatible with 1.2.0, but you still need to validate against the correct version of the schema."

This is essentially how we were thinking about this. I think there is one (potentially two) good places to say this:

1. In an FAQ about the versioning of CFF schema (on the new website).
2. Optionally: In a README for developers of tooling that uses CFF (also pulled into the website). This doesn't exist yet, but would perhaps be useful to create? Between you, @hainesr and @jspaaks there is a lot of expertise already that would be good to capture.

[hainesr]

FWIW, @jspaaks was suggesting that tooling could introduce an argument --validate-as which takes a schema version, so that this behaviour would be made explicit.

Yes, I've been wondering about this too. I think it's a good solution.