In message <CAHEJ-S6Q_J_sGZ1Pcp1G2O7wBoX9v=tvbhrylat7rgl8691...@mail.gmail.com> on Fri, 21 Sep 2018 21:28:55 +1000, Tim Hudson <[email protected]> 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 [email protected] OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
