Skip to content
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

switch to semantic versioning #123

Closed
prjemian opened this issue Apr 17, 2019 · 5 comments
Closed

switch to semantic versioning #123

prjemian opened this issue Apr 17, 2019 · 5 comments
Assignees

Comments

@prjemian
Copy link
Contributor

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

@prjemian prjemian added this to the milestone-2019-09 milestone Apr 17, 2019
@prjemian prjemian self-assigned this Apr 17, 2019
@prjemian
Copy link
Contributor Author

prjemian commented Apr 17, 2019

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
Copy link
Contributor Author

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
Copy link
Contributor Author

Changing the milestone to 1.1.0

@prjemian
Copy link
Contributor Author

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

prjemian added a commit that referenced this issue Apr 17, 2019
@carterbox
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants