Hey Bob,
The fundamental probelm with this Matthew - is that next time, if we
do this, by the next release we will
be chasing what features we have imported from 1.0.2g and 10.2.z, and
1.0.2.qq - where does it end?
We will be continuing to add functionality in here from many sources,
and so assuming we could just keep
this as the 1.0.1g version number is completely wrong.
If we do that we will be perpetually updating this to be "close to"
whatever happens to be the orthogonal openssl.
feature set, we're screwed. We'll be doing this forever, and be in a
situation where it's as bad a what it is with
ACPI, where the only safe thing to report as is "Windows" so we don't
get screwed by the software trying to
do incompatible junk.
I agree that chasing OPENSSL_VERSION_NUMBER is a lost cause, but keeping it
at 1.0.1g as a "common base" should work, in my opinion.
For the new features, applications would test (as they do now) for:
#if OPENSSL_VERSION_NUMBER >= 0x10002002L
and once LibreSSL implements them (and the application wants to support it):
#if OPENSSL_VERSION_NUMBER >= 0x10002002L \
|| LIBRESSL_VERSION_NUMBER >= 0x20001000L
instead of just breaking build, like it's happening right now.
Best regards,
Piotr Sikora
