On Sat, Sep 22, 2018 at 11:55 AM Viktor Dukhovni <openssl-us...@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.
_______________________________________________ openssl-project mailing list email@example.com https://mta.openssl.org/mailman/listinfo/openssl-project