-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Versioning protocol is unclear #47
Comments
Up until now, the assumption has been that all dictionaries and templates are under central control and move together in lockstep, making versioning simply a record of changes with no need to ensure compatibility. There are essentially two scenarios to consider: importation of attributes from a single save frame (i.e. template) and importation of an entire dictionary into a 'Head' definition. In the templating scenario, addition of an attribute to a template save block could duplicate an attribute already in the importing definition. We have currently not defined what should be done in this case during import; logically the template should take lowest precedence, in which case, additions to a template definition should not require a bump in major version number. Removal/change of an attribute in a template block could lead to an importing definition failing to be correct, so should require an increase in major version number. In theory, we would never make any changes in a non-template dictionary that would require a change in major version number as this would undermine our goal of stable, universal data names. We are probably left with simple rules for full dictionaries, such as:
|
I agree with your statements, however, a good way to start would be to define what should be consider compatible and incompatible API changes in regards to the CIF dictionaries, dictionary handling software and CIF files. The potential scenarios you provided could than serve an illustration of such changes. I propose this as a starting point: The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. The semantics of version numbers follows the guidelines described in the “Semantic Versioning 2.0.0” document.
Of course, this is a very rudimentary draft and can be extended/modified as needed. What do you think? |
DDLm group discussion yielded some detailed principles. I'll need to put these together into a proper proposal. |
Further discussion moved to #141 . |
It is not clear when the major/minor/patch version numbers should be bumped on DDLm dictionaries. This should be clarified and documented.
This issue was first raised during discussion of #35 .
The text was updated successfully, but these errors were encountered: