curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <>
Subject Re: Is Curator's semver over binary or source compatibility?
Date Tue, 10 Mar 2015 00:06:48 GMT
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 ( wrote:


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)? 



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message