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

[Viktor Dukhovni]

> On Sep 21, 2018, at 11:27 AM, Tim Hudson <tjh at cryptsoft.com> wrote:
> 
> No it isn't - as you note that isn't a valid mapping - 1.0 isn't a semantic version and there is no such thing as a fix number,
> You get three concepts and then on top of that the pre-release and the build-metadata.
> 
> Semantic versioning is about the API not the ABI.
> 
> So we could redefine what we have been telling our user all along and combine our current major+minor in a new major version.
> Making 1.0.2a be 10.2.0 in semantic version terms.

Now that we've agreed on the semantic minor number, it is easy to note that 1.0.2a's
micro number is "1" not 0, since the .0 release with 1.0.2 (no letter).  As for
the major number being "10", that's silly, we can just subtract 8, and land on
2 which is the next major number value we've not used.  There's no reason to jump
to 10.

> We cannot remove the current major version number - as that concept exists
> and we have used it all along.

And it can now become "2".

> We don't just get to tell our users for the last 20+ years what we called the
> major version (which was 0 for the first half and 1 for the second half) doesn't
> exist.

It still exists, it becomes 2.  And an "epoch nibble" of 0x2 in OPENSSL_VERSION_NUMBER
maintains proper ordering.  The users see a sane versioning scheme, that is
backwards compatible.  You seem to be somewhat fixated (pardon the language,
no disrespect intended) on some unnecessary constraint.  The encoding:

	0x2<MM><NN><FF><S>UL

just works to represent semantic version MM.NN.FF with <S> == 0xF for
final release, and 0x0--0xE for pre-releases.  There is no disruption.
The only change needed is a minor one in applications that actually
parse the nibbles, ... most don't, they just use the version number
as an ordinal for conditional compilation.

-- 
	Viktor.