> "SaaS APIs need a form that makes it easy to infer support windows and end-of-life status."
You can infer that from the Release Date though. (e.g. Version 3.4.2 Released on 2019-12-17) To me the power of Semver is that it conveys complex relations between version iterations.
For example:
- 3.4.1 -> 3.4.2 is just fixing bugs in existing functionality
- 3.4.2 -> 3.5.0 is an upgrade containing non-breaking changes
- 3.5.0 -> 4.0.0 is an upgrade containing breaking changes
As a developer, Semver + release date seems to convey everything date based versioning does plus I get the advantage of understanding at glance the importance and risk profile of each release.
Note, this system does not reduce my obligation to run my own tests to verify that the version has in fact lived up to its intention (i.e. a minor version bump did not introduce a breaking change). Even though my obligation is not reduced, it does act as a filter to help prioritize development time for evaluation of performing upgrades.
You can infer that from the Release Date though. (e.g. Version 3.4.2 Released on 2019-12-17) To me the power of Semver is that it conveys complex relations between version iterations.
For example:
- 3.4.1 -> 3.4.2 is just fixing bugs in existing functionality
- 3.4.2 -> 3.5.0 is an upgrade containing non-breaking changes
- 3.5.0 -> 4.0.0 is an upgrade containing breaking changes
As a developer, Semver + release date seems to convey everything date based versioning does plus I get the advantage of understanding at glance the importance and risk profile of each release.
Note, this system does not reduce my obligation to run my own tests to verify that the version has in fact lived up to its intention (i.e. a minor version bump did not introduce a breaking change). Even though my obligation is not reduced, it does act as a filter to help prioritize development time for evaluation of performing upgrades.