> There is a way to programatically compare an interface and bump a semver string automatically, but down that path lies Swagger diffing No, you cannot do this

> There is a way to programatically compare an interface and bump a semver string automatically, but down that path lies Swagger diffing No, you cannot do this. If the semantics of an API have changed in a backwards-incompatible way, even if the structure (name, parameters, types) did not, then you must do a semver major bump. If you somehow are disciplined enough to never change semantics incompatibility for a defined API and you make a new endpoint, then you don't really need semver at the product level. You need a way of conveying what APIs exist, but a mechanical version like 1.200.0 would work for that, or just client discovery. > Without outside information, when trying to communicate a feature or a bugfix, whats easier, "/foo was added in version 27" or "/foo was added in 2008.02.28" ? Using the date does not work if you release version 26.1 on March 1st. CalVer is great for the limited use cases where you never maintain stable branches and all your clients can use the latest version - but at that point, ideally you don't need versions at all, just use HEAD. If your clients cannot reliably and automatically use the latest HEAD, then that's a sign that stable branches are a problem you will soon have to think about. CalVer where you pick some date of branching and add a point release (e.g., "Ubuntu 18.04.2 LTS," released well after April 2018 but part of a stable branch cut in April 2018) also works well, but cannot be automated in the fashion the author advocates, and certainly cannot answer "When was this feature added," because the feature could have been backported to the stable branch.