CodeCamp2017: change versioning procedures

[prjemian]

Versioning of each base class has not been so useful and the CodeCamp has requested some changes. Since the overall repository is versioned, the various NXDL files that are part of the repository are a snapshot at the time of the repository release. Version numbers of base classes seem unnecessary. Tagging of base classes has led to clutter in the tag history (now more than 100 tags) of the definitions repository.

However, the version number of application definitions has value to the community interested in that definition and should be retained.

The use of semantic versioning is not the best fit for the release practice of the NeXus definitions. The assignment of a revision being either major or minor adds discussion of little benefit, given the depth of description in the release notes now. A simpler practice is desired.

• Base class version (in the NXDL file) can be removed.
• NXDL version number for base classes should be made optional in the XML Schema.
• For future releases, switch from semantic versioning to calendar versioning.
  • For example, the proposed March 2018 release NXDL 3.4 would be named 2018.3 (yyyy.mm). This change would still fit the tools that Python uses to automate version handling yet make clear to our community the date of any release.
  • Adopt a practice of release candidates named yyyy.mm.rc# (where # starts from 1, as needed), prior to final release of yyyy.m to resolve last minute changes that otherwise might require moving of the tag from one commit to another.
  • The final release candidate would gain full approval from the reviewers before the yyyy.mm release is tagged.
• Post the documentation of the new release after the final release has been tagged (since the documentation build process uses the GitHub tag as the published version text).
• Make sure the release procedures make note of these changes.

[prjemian]

Changed bullet list in issue's original statement to be a checklist. As items become checked, cite a reference to the commit hash, issue comment, or equal. Close this issue once all are checked.

[prjemian]

To remove the version attribute from all NXDL files, remove this part from the NXDL Schema:

https://github.com/nexusformat/definitions/blob/master/nxdl.xsd#L230

[prjemian]

How can we retrieve any arbitrary version of a specific NXDL?

[prjemian]

We look through the releases on github:

• start here: https://github.com/nexusformat/definitions/releases
• look for the tag
• look through the source tree of that tag for the NXDL file

[zjttoefs]

We're almost there. Would it make sense to release now, or do we need to have all done before making a milestone release? @prjemian?

[prjemian]

I'd like to get all changes we currently plan to the NXDL into one release rather than spread out.

[zjttoefs]

Makes sense. Feel free to pull in all the tickets that I moved that you still want to address in this round. But in the telco we felt having releases at moderately regular intervals is more important than having completed all the work we could think of.

[prjemian]

Agreed

[prjemian]

The last two items should be resolved by #616

[prjemian]

Since #616 is to remove the NXDL version number, that will be the action.

[prjemian]

With those two actions being moved to #616, I'll tick them off here and close this issue. That work will be done in a branch.