Hello again,
We've had more chats about the metadata version number - and realised semver may be a better solution, so (I'm sorry but) my answer above is no longer correct (as I said, you are helping us improve 😉 )
So the revised answer to:
wu-lee Is version expected to be an integer, or a real number, or can it be a dotted string like "1.3.0"?
is YES.
The idea is to use versions numbers as per the format: major.minor.patch e.g. my_schema-v1.1.1.json
with only the major version changes introducing backwards-incompatible changes to the schema.
Breaking change would be anything that could cause data that was valid against the previous version to be invalid against the new version (eg. smaller max size, removed enum values, more restrictive regex pattern, new required fields).
Regarding minor and patches, our thought is that a minor change could be any non-breaking change that affects the data (or potential data) in any way (eg new non-required fields, additional enum values, etc.), and a patch would be a change to parts of the schema that don't change the data, such as rewording field descriptions (presuming the meaning of the field stays equivalent), schema annotations, re-ordering fields, or moving fields between the library and the schema itself (eg, moving a field definition out of the schema and into the library).
So file names should also be updated accordingly:
The name should be the name of your schema, using underscores, appended with a hyphenated version number as per semver, e.g. my_schema-v1.1.1.json
, or solidarity_economy_schema-v1.1.1.json
This is not implemented in the existing schemas (except the not-yet-published ecovillage schema), but I will create an issue and update the existing schemas accordingly.
Sorry to mess you around but we think this will be the best way to handle file names and version numbers going forward.
Oli