address@hidden writes:
> The question is: do the following changes require a major version
number change?
I'd say yes.
> But semantic versioning is not clear on file formats (to me at
least). If the
> changes above alow H5MD software written recently to handle 1.0 and
1.1 (for
> instance), does it qualify as "backwards-compatible"?
My interpretation is that any software relying in any way on guarantees
made
in specification 1.0 can fail on a file that is valid under a new
specification,
then that new specification is not backwards-compatible.
The current specification says that there must be a "time" dataset and
it must be real-valued. A trajectory reader may therefore access
"time" without checking for its existence, and assume that a read
operation will return a real-type array. Any of your proposals 1-3
breaks such a reader.
> Personally, I don't care for the result. What is important is that
> we may find a suitable solution. Also, given H5MD's recent
> character, I consider it possible to make such changes. The number
> of software using H5MD is still small and the improvements
> discussed recently might prove important to get a wider use.
Exactly my view. It is well possible that the first widely used H5MD
version will be 3.0, but that's fine with me. Everyone writing H5MD
software now should be aware of the risk of change.