On Fri, Jul 11, 2014 at 4:37 PM, Bob Beck <b...@obtuse.com> wrote: > 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?
It ends whenever it stops helping portability for apps that are currently written for OpenSSL. We've expressly decided to ignore any API/ABI compatibility guarantees with OpenSSL, so an OpenSSL version number is inherently just a best effort to make things easier on applications to transition from OpenSSL to LibreSSL. Clang went through this same process with code that did GCC version checks. Today Clang still claims it's GCC 4.2, but in a separate version it reveals it's Clang 3.5. Existing code that only knows to check for older versions of GCC (e.g., OpenBSD's <sys/cdefs.h>) continues work just fine with Clang, because it picks up all of the definitions targeted towards GCC 4.2. New code that wants to make use of features in GCC 4.7 and Clang 3.5 though needs to check for both; but even if it doesn't, if it includes fallback for older versions of GCC it should still work okay with Clang. Concrete analogy: suppose LibreSSL 2.1 and OpenSSL 1.1 both add some new feature, and an application that wants to be compatible with both wants to make use of that feature. How do they version check for its availability? Naively, it would be #if LibreSSL >= 2.1 || OpenSSL >= 1.1 but that's going to cause the application to break when compiled with older versions of LibreSSL. It would actually needs to be #if LibreSSL >= 2.1 || (!defined(LibreSSL) && OpenSSL >= 1.1) We don't gain anything by making people need to write the latter, IMO.
