The comment from Eric explains how we use it: Essentially, it tells you the API compatibility between multiple dependencies. For example, If you have version 1.0.0 and 1.0.1, you can use either one and you will not run into errors due to API conflicts (i.e. in Java, no ClassNotFound or NoSuchMethod type exceptions) If you have 1.0.0 and 1.1.0, you can replace 1.0.0 with 1.1.0 and you will not have errors due to API conflicts. If you try to swap 1.0.0 in place of something that depends on 1.1.0, however, you *might* have errors due to API conflicts. I.e. you can go forward without errors, but not backwards If you have 1.0.0 and 2.0.0, you will likely have errors due to API conflicts if you replace either one with the other.
On March 9, 2015 at 6:18:16 PM, Sean Busbey ([email protected]) wrote: Hi! I'm very happy to see that Curator has adopted semver[1]. A couple of things that aren't immediately obvious: 1) Is the semver promise over binary compatibility, source compatibility, behavior compatibility or some combination thereof? 2) Is the semver promise over all public/protected things in all the published artifacts, or just some subset (e.g. just curator-client or curator-recipes, or some set of packages)? [1]: https://cwiki.apache.org/confluence/display/CURATOR/For+Curator+Committers#ForCuratorCommitters-versioning -- Sean
