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

[Matt Caswell]

On 21/09/18 11:48, Tim Hudson wrote:
> On Fri, Sep 21, 2018 at 7:58 PM Richard Levitte <levitte at openssl.org
> <mailto:levitte at openssl.org>> wrote:
> 
>     Our FAQ says that such changes *may* be part of a major
>     release (we don't guarantee that breaking changes won't happen), while
>     semantic versioning says that major releases *do* incur backward
>     incompatible API changes.
> 
> 
> I think you are misreading the semantic versioning usage - it states
> when things MUST happen.
> It does not state that you MUST NOT change a version if the trigger
> event has not occurred.
> 
> Semantic versioning also requires you to explicitly declare what your
> public API is in a "precise and comprehensive" manner.
> What do you consider the public API of OpenSSL?
> 
> That is pretty much a prerequisite for actually adopting semantic
> versioning.
> 
> I also think the concept of reinterpreting the current major version
> number into an epoch as you propose is not something that we should be
> doing.
> We have defined the first digit as our major version number - and
> changing that in my view at least would be going completely against the
> principles of semantic versioning.
> The version itself is meant to be purely X.Y.Z[-PRERELEASE] or
> X.Y.Z[+BUILDMETA] and your suggested encoding is not that at all.
> 
> What you have is EPOCH.X.Y.Z.FIX.STATUS - where EPOCH and STATUS are not
> concepts contained within semantic versioning.

I think this is an incorrect interpretation of Richard's proposal. The
OPENSSL_VERSION_NUMBER value is an *integer* value. It does not and
cannot ever conform to semantic versioning because, because version
numbers in that scheme are *strings* in a specific format, where
characters such as "." and "-" have special meanings.

The semantic version for openssl would be the value of the
OPENSSL_VERSION_NUMBER_TEXT macro (if PR #7285 gets merged).

If we were to adopt semantic versioning then the OPENSSL_VERSION_NUMBER
macro would be an OpenSSL specific encoding of the semantic version
number, useful for the purpose of comparing different version numbers
such that the precedence rules of semantic versioning still apply.

As an OpenSSL specific encoding, we can choose to encode it in any way
we like. This *includes* having a status value if we so wish (and that
actually fits quite nicely with the semantic versioning concept of
pre-releases)



> 
> Basically adopting semantic versioning actually requires something
> different to what has been proposed in my view.
> 
> I would suggest it means our current version encoding in an integer
> of MNNFFPPS becomes simply MNNFF000 and the information for PP and S is
> moved elsewhere as semantic versioning defines those concepts
> differently (as noted above).
> 
> Part of our challenge is ensuring we don't cause unnecessary breakage
> for users:
> 
> Vendors change the text string to add additional indicators for their
> variations.
> Otherwise developers use the current integer version for feature testing
> - and it needs to remain compatible enough.
> 
> I haven't seen any code actually testing the S field within the version
> or doing anything specific with the PP version - other than reporting it
> to the user.

The S field remains useful for checking precedence, i.e. knowing that
1.1.1-pre1 is an older version that 1.1.1.


Matt