On Sat, Sep 22, 2018 at 12:32 AM Viktor Dukhovni <openssl-us...@dukhovni.org>
wrote:

> > On Sep 21, 2018, at 10:07 AM, Tim Hudson <t...@cryptsoft.com> wrote:
> >
> > And the output you get:
> >
> > 0x10102000
>
> The trouble is that existing software expects to potential ABI changes
> resulting from changes in the 2nd and 3rd nibbles, and if the major
> version is just in the first nibble, our minor version changes will
> look like major number changes to such software.
>

The problem is that we documented a major.minor.fix.patch as our versioning
scheme and semantic versioning is different.
Semantic versioning does not allow for breaking changes on the minor
version - and that is what we do in OpenSSL currently.
Part of the requests that have come in for semantic versioning is to
actually do what is "expected".

Basically our significant version changes alter the minor version field in
the OPENSSL_VERSION_NUMBER structure.
And we have loosely referred to those as major releases but not changed the
actual major version field - but the minor.

The simple way to look at this: for OpenSSL-1.0.2a:
- what is the major version number - the answer is clearly "1".
- what is the minor version number - the answer is clearly "0"
- what is the fix version number - the answer is clear "2"
- what is the patch version number - the answer is clearly "a"

If you repeat that in semantic versioning concepts just using the labels
for mapping you get:
- what is the major version number - the answer is clearly "1".
- what is the minor version number - the answer is clearly "0"
- what is the fix version number - there is no such thing
- what is the patch version number - the answer is clearly "2" (reusing the
fix version)

If you repeat that in semantic versioning concepts just using the actual
definitions:
- what is the major version number - the answer is clearly "1".
- what is the minor version number - the answer is probably "2"
- what is the fix version number - there is no such thing
- what is the patch version number - the answer is probably "0"

Semantic versioning does not have the concept of a fix version separate
from a patch version - those are just a fix version.
If you add or deprecate APIs you have a new minor version. If you fix bugs
without touching the API is it a patch version.
If you break anything in the API is a major version.
It is completely totally about the API itself.

And for OpenSSL we are API compatible for most releases - except when we
did the major change for 1.1.0 which in reality semantic versioning would
have called 2.0.0

Semantic versioning does not have the concept of an API and a ABI
distinction.
In OpenSSL we have if the major.minor is the same then we are ABI
compatible. That is what doesn't exist in the semantic versioning approach
- it is about the API.

Effectively the current "minor" version disappears.

Tim.
_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Reply via email to