[openssl-project] A proposal for an updated OpenSSL version scheme (v2)
openssl-users at dukhovni.org
Fri Sep 21 17:24:33 UTC 2018
> 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
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
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.
More information about the openssl-project