switch to semantic versioning

[prjemian]

@carterbox makes the recommendation that apstools should use semantic versioning rather than its current scheme of calendar-based versioning.

[prjemian]

Been testing the mechanics and consequences of changing the software versioning scheme using the https://github.com/prjemian/ainawuffa/releases repository.

Some things to note:

• higher numbered versions will always be selected in preference to lower numbered, even if the lower number is newer

• conda packaging (using versioneer) is based on git tags, not GitHub releases

• It takes a couple steps to upgrade a conda installation from version 2019.nnnn to newer version 2.0.m

  1. add a conda-meta/pinned declaration for apstools < 2000 in the conda environment
  2. conda update -c aps-anl-tag -c aps-anl-dev apstools (should change to 2.0.m)

Might be good to remove the GitHub release for any of the 2018 - 2019 releases. Leave the tags in place. They will be a nuisance and a constant reminder about this.

Even if the 2019.* releases and conda packages are removed, it may still be necessary to uninstall and reinstall apstools to effect an update:

1. conda uninstall -y apstools
2. conda install -c aps-anl-tag -c aps-anl-dev "apstools < 2000"

[prjemian]

Last pre-release (in development series) was https://github.com/BCDA-APS/apstools/releases/tag/0.0.40.
First CalVer release was https://github.com/BCDA-APS/apstools/releases/tag/2019.0103.0.
Latest CalVer release was https://github.com/BCDA-APS/apstools/releases/tag/2019.0301.0.

Accepting that the CalVer releases are (effectively) 1.0 series and the change in versioning scheme does not break the API, then next version would be 1.1.0.

[prjemian]

Changing the milestone to 1.1.0

[prjemian]

The only work to be done here is to use semver during the next release process.

[carterbox]

To be clear, calendar versioning can be semantic, but doing so limits you to making API breaking changes (at most) once a year (this might be desirable for stability?).

Additionally, you could take a hybrid approach, where the major version number is the year that the version was originally released, then if you have no API breaking changes, you can just keep incrementing the minor version number past 12 until you have API breaking changes again.