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

[Tim Hudson]

On Sat, Sep 22, 2018 at 11:55 AM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> this is an ad-hoc encoding with monitonicity as the
> the only constraint.
>

If you start from the position that the encoding of OPENSSL_VERSION_NUMBER
is free to change so long as the resulting value is larger than what we
have been using for all previous versions then a whole range of options
come into play.
But we shouldn't assert that we aren't changing the meaning of
OPENSSL_VERSION_NUMBER - and that is what others have been doing on this
thread - and what your previous email also asserted.

It is a *breaking* change in our comments and our documentation and in what
our users are expecting. Basically it is an API and ABI change - we said
what the number means and we are changing that.
The impact of the breaking change for those using it for pure feature
testing for API difference handling (where it isn't actually parsed) can be
minimised just by always having a larger number that all previous uses.
The impact of the breaking change on anyone actually following our
documented encoding cannot.
i.e. openssh
<https://github.com/openssh/openssh-portable/blob/master/openbsd-compat/openssl-compat.c#L42-L67>
as
one example Richard pointed out.
That isn't the only code that actually believes our header files and
documentation :-)

Semantic versioning is about MAJOR.MINOR.PATCH with specific meanings.
There is no FIX concept as such. There is PRERELEASE and METADATA.
One of our existing concepts disappears - we have MAJOR.MINOR.FIX.PATCH
currently and we also encode STATUS as a concept (which we can map mostly
to PRERELEASE).

And if we are changing to fit into semantic versioning we need to use its
concepts and naming and not our present ones.
A merge of concepts pretty much goes against the point of semantic
versioning.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180922/c24c0f15/attachment-0001.html>