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

[Richard Levitte]

In message <CAHEJ-S6Q_J_sGZ1Pcp1G2O7wBoX9v=TvBHryLAt7RgL86910dA at mail.gmail.com> on Fri, 21 Sep 2018 21:28:55 +1000, Tim Hudson <tjh at cryptsoft.com> said:

> So as a concrete example - taking master and the current OPENSSL_VERSION_TEXT value.
> 
> "OpenSSL 1.1.2-dev xx XXX xxxx"
> 
> would become
> 
> "1.1.2-dev+xx.XXX.xxxx"

No, it would become "1.1.2-dev"

I have no idea why you want to shove the date template into the
version number.

> That is what I understand is the point of semantic versioning. You know how to pull apart the
> version string.
> -dev indicates a pre-release version known as "dev"
> +xx.XXX.xxxx indicates build metadata.

I haven't seen "xx XXX xxxx" as build metadata, only as a template of
the release date, which is part of how we display the version (with
'openssl version').  I don't see it as part of the version string, nor
have our script that do parse out the version from that string *ever*
done that.  You'd have to argue why we should start making it part of
the version now...

> The underlying release is major 1, minor 1, patch 2.

No.  1.1.1 is a minor (feature) release visavi 1.1.0.  1.1.0 is a
major release visavi 1.0.x.  We've talked about 1.2.0 as the next
major release.  Semantically (!) speaking, that tells me that the
middle number is the major version number, the last number is the
minor version number, and the letters after that represent the patch
version number.
This is how we have acted, and this is how our FAQ describes our
version scheme since April 2012.

> But for semantic versioning where we allow API breakage in our
> current minor version we would have to shift everything left.
> And we would then have "1.2.0-dev+xx.XXX.xxxx" if the planned new
> release wasn't guaranteed API non-breaking with the previous release
> (1.1.1).

Yes (except the '+xx.XXX.xxxx' part, just drop that please).  But I'm
not proposing that we do this change as a part of a minor release, I
propose that we do this on the next major release.  In other words,
this would allow us to continue according to the current scheme for
any 1.1.x if we would choose to release one, but that the next major
release would be called 2.0.0 instead of 1.2.0, that the next minor
(feature) release after that would be called 2.1.0 instead of 1.2.1,
and that the fix releases would be called 2.0.1 instead of 1.2.0a,
2.1.1 instead of 1.2.1a, etc etc etc.

Is this clearer to you?

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/