|
From: | Felix Höfling |
Subject: | Re: [h5md-user] Make "time" optional? |
Date: | Wed, 16 Jul 2014 16:45:33 +0200 |
User-agent: | Opera Mail/12.16 (Linux) |
Am 16.07.2014, 13:20 Uhr, schrieb Pierre de Buyl <address@hidden>:
Concerning the versioning, we need an (internal) definition of what "backwards compatiblity" means. As I indicated earlier, I suggest something like "For y > x, the format version 1.y is backwards compatible to 1.x if a reader expecting 1.y can deal with 1.x."An old reader expecting 1.x can not handle 1.y, of course. This means that1.y is a superset of 1.x, it may be more relaxed or include additional fields."""The version x.y.z of the H5MD specification follows semantic versioning(Preston-Werner): A change of the major version number x indicatesbackwards-incompatible changes to the file structure. A change of the minor version number y indicates backwards-compatible changes to the file structure."""If we make the proposed change, 1.0 readers will not be able to handle 1.1 files. If I understand well, this falls under "backwards-incompatible changes tothe file structure". P
Semantic versioning has basically been invented for software. If a future software version can process old input files, it is backwards compatible. In this sense, a file reader for the new file format processes old files as new ones (i.e., without extra hooks). However, there may be different interpretations in the context of a file format.
The interpretation that old readers must be able to handle new files drastically limits the possible "minor" changes to the file format, and is IMO useless. Translating to the software domain, it means that old software must be able to process future input files.
To make things more specific: making a previously mandatory field optional is backwards compatible. Changing the overall tree structure (or just renaming /particles → /atoms) is not.
Felix
[Prev in Thread] | Current Thread | [Next in Thread] |