<div dir="ltr"><div class="gmail_extra">Hi Stephan,<br><br>>`unintended' behavior (what's that in the first place)<br><br>For
 example, if I have class Foo with method add(int, int) that behaves as one might expect, except for the following edge case: Foo.add(0, -1) = 256. That 
is unintended behavior. If I fix my implementation so that Foo.add(0, 
-1) = -1 I have changed behavior but not the traditional definition of public API[1,2]. Thus this change is
 within the scope of the PATCH version of SemVer.<br><br>>A strict definition of the public API would classify a bug-fix that changes the output of a method<br>
>from wrong to correct as a break, i.e. MAJOR upgrade.<br><br>> and thanks to the SemVer policy to roll PATCH on MINOR (1.1.5 > 1.2.0)<br><br></div><div class="gmail_extra">Just to make sure we're on the same page - when you say "changes the output", I assume you mean "changes the behavior but not the API - i.e. return type is unchanged" because SemVer already requires bug fixes that change API to be MAJOR version bumps.<br><br></div><div class="gmail_extra">In that case, I think it would be cleaner to just eliminate the PATCH number - because every bug fix necessarily changes behavior, right? So with this scheme, MAJOR increases = "existing behavior has changed", and MINOR increases = "new behavior is available".<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Some problems with creating this versioning scheme:<br>1. MAJOR versions will increase rapidly. This is aesthetic, but one that people can react very negatively to - and can certainly be confusing if people don't expect MAJOR version bumps to cover bug fixes.<br></div><div class="gmail_extra">2. It's one more thing for external developers to learn. We can't just say "we use SemVer".<br></div><div class="gmail_extra">3. Since this is an internal versioning scheme, it may not be easy to compare our versions with external project versions that use SemVer.<br></div><div class="gmail_extra">4. There will be false negatives for MAJOR version compatibility comparisons (instead of what could be considered false positives with SemVer)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Unfortunately, #1 above alone makes it very unlikely that we would want to adopt this use of version numbers. But what you're trying to do here - ensure compatibility - is fantastic and something that would be great to have.<br><br></div><div class="gmail_extra">So let's take a step back and look at what guarantees we do and do not have right now:<br><br></div><div class="gmail_extra">+ We have reproducible builds (release couplings, which requires -some- versioning scheme to be used)<br></div><div class="gmail_extra">+ We have API compatibility (SemVer)<br><br></div><div class="gmail_extra">- We do not have strict behavior compatibility<br></div><div class="gmail_extra"></div><div class="gmail_extra">- We do not have dependency compatibility<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Behavior and dependency compatibility are very closely related - if they were covered by a versioning scheme, we could automatically answer the question "is it safe to drop in version X to replace version Y?".<br><br></div><div class="gmail_extra">However, I do not think we should conflate these concerns with SemVer. Instead, two potential options would be:<br><br></div><div class="gmail_extra">1) Continue to use SemVer, accept its limitations, be content with reproducibility.<br></div><div class="gmail_extra">2) Create a separate versioning scheme that covers behavior and dependency compatibility. Use it in tandem with SemVer.<br><br></div><div class="gmail_extra">If anyone can think of other examples of versioned guarantees that would be useful to have, or counter-examples to any claims made here - please share!<br><br></div><div class="gmail_extra">Also, please let me know if any of this is confusing and/or additional examples would be useful.<br><br></div><div class="gmail_extra">Thanks again for the continued discussion,<br></div><div class="gmail_extra">Mark<br></div><div class="gmail_extra"><br>[1] <a href="http://en.wikipedia.org/wiki/Application_programming_interface#API_in_object-oriented_languages">http://en.wikipedia.org/wiki/Application_programming_interface#API_in_object-oriented_languages</a><br>[2] <a href="http://stackoverflow.com/questions/2954372/difference-between-spi-and-api">http://stackoverflow.com/questions/2954372/difference-between-spi-and-api</a><br></div></div>