Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
..."
Incompatibility is a little unclear here, though, and may be stricter than we are accustomed to when it comes to shared libraries.
From the perspective of a customer of an ESDK, adding a new optional input parameter is not a breaking change. But from the perspective of an ESDK implementation, it is, since the implementation is now "broken" in that it does not match the specification "MUST accept an optional parameter Foo".
The correct analogy might just be that the specification is like a set of interfaces or traits, and changes that break either users or implementors of those concepts should be considered breaking changes.
Our versioning document states:
"We follow Semantic Versioning.
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
..."
Incompatibility is a little unclear here, though, and may be stricter than we are accustomed to when it comes to shared libraries.
From the perspective of a customer of an ESDK, adding a new optional input parameter is not a breaking change. But from the perspective of an ESDK implementation, it is, since the implementation is now "broken" in that it does not match the specification "MUST accept an optional parameter Foo".
The correct analogy might just be that the specification is like a set of interfaces or traits, and changes that break either users or implementors of those concepts should be considered breaking changes.