Add versioning to format

[ivirshup]

This PR adds a "version" attribute to the format.

This proposes a two digit version specifier: MAJOR.MINOR, like a truncated semver specifier.

• MAJOR increments mean that there are breaking changes
• MINOR increments indicate additions. Any minor increments must strictly be additions to the specification and must be compatible with all previous minor releases within the major release series. If a reader is capable of reading a version 1.1 store, it must be able to read a version 1.0 store.
• There is no PATCH, because it's unclear what a bug fix means in the context of specifications

Possible addition: development/ release candidate versioning

I would like to be able to have release candidates/ development versions for this specification. The main thing here is to give us a way to hack on the specification before committing to a final version. That way any files we write and share during this phase are clearly marked as potentially being invalid. I would propose following semantic versioning or python's PEP440 to support release candidates and development versions (notes on compatibility). The PEP is suggested since I don't believe I've seen many non-python projects use the semver release candidates and dev semantics.

	semver	PEP440
Development	a little unclear	X.Y.devN
Release Candidate	X.Y-rcN	X.YrcN

This wouldn't strictly need to be documented in the spec, but it would be good to document somewhere.

Alternatives

No MINOR

When I reached out to OME-NGFF I was told they only intend to have a single digit version. They are only doing versions like 0.4 right now because it is still broadly unstable.

We could do the same thing here. However, we have discussed multiple additions that would not neccesitate full nD support, but would increase the scope of the spec. This includes: chunking, triangular formats, masked formats.

PATCH

The PATCH is not included because it's not clear what a bug fix for a file format should mean. There are specifications that use a patch release:

Prior art

• CF conventions (NetCDF Climate and Forecast Metadata Conventions) uses a similar versioning scheme: http://cfconventions.org/Data/cf-conventions/cf-conventions-1.10/cf-conventions.html#revhistory
• Arrow specifies the library and format number separately. While they do use 3 digits, I can't find an example where the third digit is used for the format post 1.0, and versions are referred to by two digits in the documentation and flat buffer spec
• SBOL (systems biology language) uses a three digit version, though I don't believe they are following semver (e.g. 3.0.1 seems like it added features)
• EML (Ecological metadata language) uses a three digit version where bug fixes can include typos in the specification. I don't think these need to be included in the file format, through do indicate a need for documentation that can be versioned separately from the format itself.

[github-actions[bot]]

Automated Review URLs

• render latest/index.bs

[willow-ahrens]

These changes look great! Could we also list the current version at the top of the spec document?

[BenBrock]

@ivirshup @willow-ahrens I added the version number to the top of the file and also changed the version to 0.5, which is what we had written in the notes.

Is this ready to merge?

[ivirshup]

Sorry for the late reply! Traveling for the past couple weeks

I would prefer to start with either 0.1 or 1.0.dev0

[willow-ahrens]

LGTM! I just changed the version to 0.1 as suggested