Description
@marqh proposes that we should follow the principles of semantic versioning for this project, as outlined at http://semver.org/ .
I agree, both for this particular package and in general. For the moment, the version number of this package is explicitly set to be in the 0.x range (starting at 0.1), to indicate API changes at any time, and at the conclusion of the current development phase we'll release 1.0.0 (followed by any 1.0.x bugfix releases that might be needed).
A bigger issue is to ensure that dependencies also use semantic versioning, since that's what's necessary for everything to play together nicely. This project depends directly on Iris and Cartopy, which it would seem already follow semantic versioning, plus param, paramnb, and holoviews. paramnb is a new package just created for this project, so we can simply ensure that we follow the semantic versioning guidelines. So far, however, param and holoviews have only been roughly semantically versioned; i.e., the version numbers were chosen on a "preponderance of evidence" (named for what best characterizes this release, overall), not on a "one strike and you're out" basis (any backwards-incompatible change requires bumping the major version, and any new functionality requires bumping the minor version). Thus their version naming works semantically only for those users avoiding the little bits that did change between minor or bugfix releases. The intention when naming those releases originally was to avoid over-promising on a new release when we were "just making one little minor change" :-), but as soon as any of these packages have any widespread installed userbase (which clearly does apply to param and holoviews now) then it's important to treat even a small change seriously, since it could cause serious problems for a subset of the users. So, can we agree to follow semantic versioning henceforth, even for minor changes, for param, paramnb, and holoviews?
Activity