<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="auto"><div class="gmail_quote"><div dir="ltr">On Sat, 22 Sep. 2018, 3:24 am Viktor Dukhovni, <<a href="mailto:openssl-users@dukhovni.org" target="_blank">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On Sep 21, 2018, at 12:50 PM, Tim Hudson <<a href="mailto:tjh@cryptsoft.com" rel="noreferrer" target="_blank">tjh@cryptsoft.com</a>> wrote:<br>> If that is the case then our current practice of allowing ABI breakage with<br>
> minor release changes (the middle number we document as the minor release number)<br>
> has to change.<br>CORRECTION: As advertised when 1.0.0 first came out, and repeated in our release<br>
policy:<br> As of release 1.0.0 the OpenSSL versioning scheme was improved<br>
to better meet developers' and vendors' expectations. Letter<br>
releases, such as 1.0.2a, exclusively contain bug and security<br>
fixes and no new features. Minor releases that change the<br>
last digit, e.g. 1.1.0 vs. 1.1.1, can and are likely to<br>
contain new features, but in a way that does not break binary<br>
compatibility. This means that an application compiled and<br>
dynamically linked with 1.1.0 does not need to be recompiled<br>
when the shared library is updated to 1.1.1. It should be<br>
noted that some features are transparent to the application<br>
such as the maximum negotiated TLS version and cipher suites,<br>
performance improvements and so on. There is no need to<br>
recompile applications to benefit from these features.<br></blockquote><div><br></div><div><br></div>I have to disagree here. We said things about <i>minor releases</i> and <i>major releases</i> but we didn't say things about the version numbers or change the documentation or code comments to say the first digit was meaningless and that we have shifted the definition of what X.Y.Z means. </div><div class="gmail_quote"><div dir="auto"><br></div><div dir="auto">That parsing of history I think is at best a stretch and not supportable and also not what our <b>users</b> think.</div><div dir="auto"><br></div><div dir="auto">Our users don't call 1.0.2 the 0.2 release of OpenSSL. Our users don't call 1.0.0 the 0.0 release. There isn't a short hand or acceptance or a decision communicated to conceptually drop the 1. off the front of our versioning.</div><div>Your logic and practice is saying you see the first two digits as the major version number - that's fine - you are welcome to take an ABI compatible short hand to refer to version - but that doesn't mean we changed the definition of our versioning system.</div><div>What you are tracking there is effectively the SHLIB version.</div><div dir="auto"><br></div><div dir="auto">So if our users don't think that, and our code comments don't stay that, and our pod documentation doesn't say that and users have the first part in their masks and don't just ignore it then I don't think it is supportable to claim we told everyone it was a meaningless first digit and changed our definition of our versioning scheme back at the 1.0.0 release.</div><div dir="auto"><br></div><div dir="auto">Currently when we make minor API changes that aren't breaking we update the fix version number. When we make major API changes which we expect to be breaking we update the minor version number. </div><div>Now think about the transition from 1.1.0 to 1.1.1 - that is by any reasonable definition <b>a major release</b> - but we don't update the major version number by either definition of the major version number.</div><div>We call it in our website a "feature release" - yet more terminology to dance around our version numbering scheme.</div><div>Read the actual <a href="https://www.openssl.org/blog/blog/2018/09/11/release111/">blog post</a> and try to parse that as <b>a minor release</b> - it isn't - it is <b>a major release</b> - but we did not change the <b>major release number </b>even if we accepted the theory and your definition that the first number is meaningless and it is only the second number that is the real major version and the third number isn't a fix version is it actually the minor version. The implications of that view point aren't supported by our actions.</div><div><br></div><div dir="auto">We did not say we are redefining the concept of our release numbering scheme - we just defined what API impacts there were and we used "major" and "minor" about <b>release efforts and impacts</b> - not about changing the definition of the parts of the OPENSSL_VERSION_NUMBER macro and the corresponding meaning of what SSLeay_version_num() and now OpenSSL_version_num() returns. This is a core part of our API.</div><div dir="auto"><br></div><div dir="auto">Remember that SSLeay_version_num() was only renamed OpenSSL_version_num() in 2015 in commit <a href="https://github.com/openssl/openssl/commit/b0700d2c8de79252ba605748a075cf2e5d670da1">b0700d2c8de79252ba605748a075cf2e5d670da1</a> as part of 1.1.0 </div><div>The first update for the top nibble indicating the major version number had changed was back in 2009 in commit <a href="https://github.com/openssl/openssl/commit/093f5d2c152489dd7733dcbb68cbf654988a496c">093f5d2c152489dd7733dcbb68cbf654988a496c</a> which is when 1.0.0 started. </div><div dir="auto"><br></div><div dir="auto">Saying that our documentation in <a href="https://github.com/openssl/openssl/blob/master/doc/man3/OPENSSL_VERSION_NUMBER.pod">doc/crypto/OPENSSL_VERSION_NUMBER.pod</a> was just forgotten to be updated and happens to be wrong (in order to support that view point) isn't matched by the actual update history - it was updated in 2014 in commit <a href="https://github.com/openssl/openssl/commit/9208640a36228b10fcdf75c8853d9410aaff19a3">9208640a36228b10fcdf75c8853d9410aaff19a3</a> and it actually changed the documentation of what the major version number encoding is - from the top two nibbles to just the top nibble. If your assertions about the history were accurate then I would expect to see a comment there that the top nibble is a meaningless epoch and the major version is encoded elsewhere. But what was done there was to <b>bring the documentation in line with the code comment</b> and also in line with reality and what our users perceive things as. <br><div dir="auto"> <br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The 2nd/3rd nibbles in OPENSSL_VERSION_NUMBER are not "the minor version number",<br>
they are just some bits in an ordinal. </blockquote><div><br></div><div>Our documentation says otherwise. Our code comments say otherwise. Our users (I assert) say otherwise.</div><div>And your rationale for this in the website statements in their plain reading also support that - you have to insert "number" in quite a few places in order to read the context of those posts as meaning we have a change in the encoding scheme for numbers.</div><div>We didn't do that.</div><div><br></div><div>So in summary, don't mix major and minor in the sense of the scope of a change in with the major version number and minor version number - that is I think where the confusion comes from in terms of your interpretation (and Richard's proposal). </div><div>We did not explicitly disconnect those concepts from their encoding in OPENSSL_VERSION_NUMBER, we did not redefine what we meant by version. </div><div>We also did not say the first two digits are the major version number and the next digit is the minor version number.</div><div><br></div><div>One of those two leaps has to be made to support your view point and I see no evidence to actually support that without inserting meaning into the <a href="https://www.openssl.org/policies/releasestrat.html">release strategy</a> that isn't actually there and conflicts with multiple other sources of information. </div><div>Remember our users read the code and sometimes the documentation when using OpenSSL - a user doesn't go and read our release strategy to see if there is some wording that happens to have updated meaning. </div><div><br></div><div>And for amusement value, I reference the "ultimate source of truth" - our entry on <a href="https://en.wikipedia.org/wiki/OpenSSL">Wikipedia </a> which lists our "major version releases" using the same sort of loose release effort scope definition with no connection to the major version number. </div><div>For wikipedia, all major.minor.fix releases are "major version releases" - and that I think actually matches our users view point.</div><div><br></div><div dir="auto"><div dir="auto">Tim.</div><div dir="auto"><br></div></div></div></div>
</div></div></div></div></div>