<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Sep 22, 2018 at 12:32 AM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Sep 21, 2018, at 10:07 AM, Tim Hudson <<a href="mailto:tjh@cryptsoft.com" target="_blank">tjh@cryptsoft.com</a>> wrote:<br>
> <br>
> And the output you get:<br>
> <br>
> 0x10102000<br>
<br>
The trouble is that existing software expects to potential ABI changes <br>
resulting from changes in the 2nd and 3rd nibbles, and if the major<br>
version is just in the first nibble, our minor version changes will<br>
look like major number changes to such software.<br></blockquote><div><br></div><div>The problem is that we documented a major.minor.fix.patch as our versioning scheme and semantic versioning is different.</div><div>Semantic versioning does not allow for breaking changes on the minor version - and that is what we do in OpenSSL currently.</div><div>Part of the requests that have come in for semantic versioning is to actually do what is "expected".</div><div><br></div><div>Basically our significant version changes alter the minor version field in the OPENSSL_VERSION_NUMBER structure.</div><div>And we have loosely referred to those as major releases but not changed the actual major version field - but the minor.</div><div><br></div><div>The simple way to look at this: for OpenSSL-1.0.2a:</div><div>- what is the major version number - the answer is clearly "1".</div><div>- what is the minor version number - the answer is clearly "0"</div><div>- what is the fix version number - the answer is clear "2"</div><div>- what is the patch version number - the answer is clearly "a"</div><div><br></div><div>If you repeat that in semantic versioning concepts just using the labels for mapping you get:</div><div><div>- what is the major version number - the answer is clearly "1".</div><div>- what is the minor version number - the answer is clearly "0"</div><div>- what is the fix version number - there is no such thing</div><div>- what is the patch version number - the answer is clearly "2" (reusing the fix version)</div><br class="gmail-Apple-interchange-newline"></div><div><div>If you repeat that in semantic versioning concepts just using the actual definitions:</div><div><div>- what is the major version number - the answer is clearly "1".</div><div>- what is the minor version number - the answer is probably "2"</div><div>- what is the fix version number - there is no such thing</div><div>- what is the patch version number - the answer is probably "0"</div><div><br></div><div>Semantic versioning does not have the concept of a fix version separate from a patch version - those are just a fix version.<br></div><div>If you add or deprecate APIs you have a new minor version. If you fix bugs without touching the API is it a patch version.</div><div>If you break anything in the API is a major version.</div><div>It is completely totally about the API itself.<br></div><div><br></div><div>And for OpenSSL we are API compatible for most releases - except when we did the major change for 1.1.0 which in reality semantic versioning would have called 2.0.0</div><div><div><br></div><div>Semantic versioning does not have the concept of an API and a ABI distinction.</div><div>In OpenSSL we have if the major.minor is the same then we are ABI compatible. That is what doesn't exist in the semantic versioning approach - it is about the API.</div><br class="gmail-Apple-interchange-newline"></div><div>Effectively the current "minor" version disappears. </div><br class="gmail-Apple-interchange-newline"></div></div><div>Tim.</div><div><br></div></div></div>