[openssl-project] A proposal for an updated OpenSSL version scheme (v2)

[Viktor Dukhovni]

> On Sep 21, 2018, at 12:50 PM, Tim Hudson <tjh at cryptsoft.com> wrote:

> If that is the case then our current practice of allowing ABI breakage with
> minor release changes (the middle number we document as the minor release number)
> has to change.

CORRECTION:  As advertised when 1.0.0 first came out, and repeated in our release
             policy:

	  As of release 1.0.0 the OpenSSL versioning scheme was improved
	  to better meet developers' and vendors' expectations. Letter
	  releases, such as 1.0.2a, exclusively contain bug and security
	  fixes and no new features. Minor releases that change the
	  last digit, e.g. 1.1.0 vs. 1.1.1, can and are likely to
	  contain new features, but in a way that does not break binary
	  compatibility. This means that an application compiled and
	  dynamically linked with 1.1.0 does not need to be recompiled
	  when the shared library is updated to 1.1.1. It should be
	  noted that some features are transparent to the application
	  such as the maximum negotiated TLS version and cipher suites,
	  performance improvements and so on. There is no need to
	  recompile applications to benefit from these features.

The text says that the *last* digit changes in "minor releases".
Presently, the combination of the first and 2nd digits are effectively
the major release number (1.1 at the moment).  Indeed well before this
discussion (for a few years now), I've been supporting OpenSSL at $WORK
by installing both 1.0.2x and 1.1.0x in:

	/opt/openssl/1.0/   - 1.0.2x directory prefix
	/opt/openssl/1.1/   - 1.1.0x directory prefix

and I plan to upgrade to shortly upgrade the 1.1.0x tree to 1.1.1x in
place, without changing the prefix.  The present major versions are
clearly two-digits, with the "1." not carrying any substantive meaning.

Your proposal gives us only one nibble for the major release, and forces
bumps in that nibble whenever the ABI changes.

> And anyone depending on checking the minor version number for ABI compatibility will break.

The 2nd/3rd nibbles in OPENSSL_VERSION_NUMBER are not "the minor version number",
they are just some bits in an ordinal.  The mapping from that ordinal to the
.../major/minor/micro/patch/status/... has evolved in the past and can evolve
again.  Applications don't generally extract these nibbles at all, they only
compare ordinals at compile time as an alternative to dynamic (autoconf) feature
test macros.

We can at some point provide functions to return extracted major/minor/micro
versions (for the runtime versions) and macros (for the compile-time versions).
Which then abstract-away the encoding, which retains meaning only as an ordinal,
and we're still free to change the encoding when requirements change, provided
we don't break strict linear ordering.

-- 
	Viktor.