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

Viktor Dukhovni openssl-users at dukhovni.org
Fri Sep 21 13:40:35 UTC 2018

I support Richard's numeric scheme as proposed, with one small change.

I think that setting the epoch to 8 to set the high bit is neither
necessary nor wise.  Though the numeric version constant should be
manifestly unsigned (UL suffix not L), and having the top 3 nibbles
for the "effective" major version maximizes compatibility with prior
practice for most users, making the number negative if treated as
signed is not a good idea at this time.

Since we're making a change to semantic versioning, I'd bump the
epoch to 2.  This means that some (not common) software that
reconstructs the version string from the numeric constant (e.g.
Postfix when warning about run-time vs. compile-time mismatch)
gets something vaguely sensible:

	0x2020000FL  -> "2.2.0" (rather than "2.0.0")

I'll have to adjust Postfix to produce better version mismatch
reports (which really should not happen since the SONAME prevents
running with an incompatible shared library, so perhaps remove the
check, but Wietse may be difficult to convince, my problem...)

> On Sep 21, 2018, at 5:58 AM, Richard Levitte <levitte at openssl.org> wrote:
> I've worked on a proposal for an update of the OpenSSL version scheme,
> to basically align ourselves with semantic versioning, most of all in
> presentation, but also in spirit, while retaining numeric
> compatibility.  This proposal is currently in the form of a Google
> Document:
> https://docs.google.com/document/d/1H3HSLxHzg7Ca3WQEU-zsOd1lUP_uJieHw5Dae34KPBs/


More information about the openssl-project mailing list