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

[Tim Hudson]

On Fri, Sep 21, 2018 at 9:02 PM Matt Caswell <matt at openssl.org> wrote:

> 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.
>

It is the version number. We have it in two forms within OpenSSL from a
code perspective  - we have an integer encoding and a text string.
They are precisely what semantic versioning is about - making sure the
versioning concept is represented in what you are using versioning for.

For OpenSSL, codewise we have two macros and two functions that let us
access the build-time version of the macros:
  OPENSSL_VERSION_NUMBER
  OPENSSL_VERSION_TEXT
  OpenSSL_version_num()
  OpenSSL_version()

We also separately have another form of version number - for shared
libraries:
The macro:
  SHLIB_VERSION_NUMBER

We also encode the version number in release packages too.

What semantic versioning is about is sorting out how we represent the
version.
It should impact both OPENSSL_VERSION_NUMBER and OPENSSL_VERSION_TEXT and
it should be consistent.

For the semantic versioning document the status indicator is handled in the
pre-release indicator.
We could limit that to a numeric number and have it in the
OPENSSL_VERSION_NUMBER but I don't think that has helped and semantic
versioning strictly defines precedence handling.

So I would see the simple mapping from semantic versioning very differently
to Richard's write up - and in fact encoding something rather differently
into the OPENSSL_VERSION_NUMBER to my reading and thinking actually goes
against the principles of semantic versioning.

i.e. OPENSSL_VERSION_NUMBER should be X.Y.Z and OPENSSL_VERSION_TEXT should
be "X.Y.Z[-patch][+buildmeta]" and that would be a simple, direct, and
expected mapping to OpenSSL for semantic versioning.

A merged approach or keeping parts of our (non-semantic) approach while not
fully adopting semantic versioning to me at least would be missing the
point.

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