> On Sep 21, 2018, at 9:35 AM, Richard Levitte <levi...@openssl.org> wrote:
>
> In that case, we should probably just thrown away
> OPENSSL_VERSION_NUMBER.
Sorry, that must not t happen and there's no need. My sense is that Tim
may end up "in the rough" on this issue, so unless there's more evidence
of support for his "strict" interpretation, I don't think you need to
consider any radical changes as yet.
Just set the high nibble to 2 for backwards compatibility, and as long as
we stick with semantic versioning, we never change it (at least not until
OpenSSL major number 256). The "epoch" nibble is then signifies the
version of the versioning scheme, and as long as we're doing semantic
versioning and the major number is 255 or less, it does not change.
If we wanted to make a concession to coëxistence with LibreSSL (which I
do not), we could go with an initial epoch of "3" rather than 2.
Personally, I think that making it clear that OPENSSL_VERSION_NUMBER
is a name in the OpenSSL and not LibreSSL namespace is a good thing.
LibreSSL should have stayed with "1.0.2" and encoded their version
elsewhere. Their squatting on "2.x.y" is their fault, and I don't
see any need to make concessions to avoid "conflicts".
Software that wants to be compatible with both, and wants to use the
version number to select implementations of various features, needs
to make LibreSSL-specific choices only when some LibreSSL-specific
macro indicates that it is compiled with LibreSSL.
--
--
Viktor.
_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
