<div dir="ltr"><div dir="ltr"><div dir="ltr">I think we have to keep OPENSSL_VERSON_NUMBER and it has to have MAJOR.MINOR.FIX in it encoded as we currently have it (where FIX is PATCH in semantic terms and our current alpha PATCH is left blank).<div>That is what I've been saying in the various emails - because we precisely need to not change the definition of what that macro is - as people interpret it.</div><div>I suggest we zero out all the other information in the OPENSSL_VERSION_NUMBER macro.</div><div>And I did also suggest we make the OPENSSL_VERSION_TEXT field precisely what semantic versioning would have us do - and either drop the things we have that don't fit or encode them following the rules.</div><div><br></div><div>I would also suggest we make that macro up using macros that use the semantic version terminology directly.</div><div>i.e. something like the following.</div><div><br></div><div>And the version number is encoded that way to not break the existing usage (except that what we currently call a fix is actually semantically named a patch).</div><div>One of the critically important parts of semantic versioning is that the API is precisely only about the major.minor.patch. </div><div><br></div><div>The examples for pre-release and build-metadata are just showing that one goes first with a hyphen and can have dot separated things, the other goes second with a plus and also can have dot separated things.</div><div>If we wanted to keep the date concept in the version text macro then we encode it correctly - or we can stop doing that sort of thing and leave it out.</div><div>The pre-release can be blank. The build metadata can be blank. </div><div><br></div><div>In semantic versioning terms this is what it would mean. </div><div>And if you want to check release/alpha/beta status you look at the OPENSSL_VERSION_PRE_RELEASE macro and we stop the release+alpha+beta indicator usage in the OPENSSL_VERSION_NUMBER macro.</div><div>It was rather limiting in its encoding format. That more rightly belongs in the semantic version string format.</div><div><br></div><div><div>#include <stdio.h></div><div><br></div><div>#define OPENSSL_MSTR_HELPER(x) #x</div><div>#define OPENSSL_MSTR(x) OPENSSL_MSTR_HELPER(x)</div><div><br></div><div>#define OPENSSL_VERSION_MAJOR 1</div><div>#define OPENSSL_VERSION_MINOR 1</div><div>#define OPENSSL_VERSION_PATCH 2</div><div>#define OPENSSL_VERSION_PRE_RELEASE "-beta1.special"</div><div>#define OPENSSL_VERSION_BUILD_METADATA "+21Sep2018.optbuild.arm"</div><div><br></div><div>#define OPENSSL_VERSION_NUMBER (long)((OPENSSL_VERSION_MAJOR<<28)|(OPENSSL_VERSION_MINOR<<20)|(OPENSSL_VERSION_PATCH<<12)) </div><div>#define OPENSSL_VERSION_TEXT OPENSSL_MSTR(OPENSSL_VERSION_MAJOR) "." OPENSSL_MSTR(OPENSSL_VERSION_MINOR) "." OPENSSL_MSTR(OPENSSL_VERSION_PATCH) OPENSSL_VERSION_PRE_RELEASE OPENSSL_VERSION_BUILD_METADATA</div><div><br></div><div>int main(void)</div><div>{</div><div> printf("0x%8lx\n",OPENSSL_VERSION_NUMBER);</div><div> printf("%d.%d.%d\n",OPENSSL_VERSION_MAJOR,OPENSSL_VERSION_MINOR,OPENSSL_VERSION_PATCH);</div><div> printf("%s\n",OPENSSL_VERSION_TEXT);</div><div>}</div></div><div><div><br></div><div>And the output you get:</div><div><br></div><div><div>0x10102000</div><div>1.1.2</div><div>1.1.2-beta1+21Sep2018.optbuild.arm</div></div><div><br></div><div>Tim.</div><div><br></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 21, 2018 at 11:36 PM Richard Levitte <<a href="mailto:levitte@openssl.org">levitte@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In message <CAHEJ-S7Uww84Np+JhWYgTZ26Eo7oszK+y=<a href="mailto:w2o_njr8bFOorsmw@mail.gmail.com" target="_blank">w2o_njr8bFOorsmw@mail.gmail.com</a>> on Fri, 21 Sep 2018 23:01:03 +1000, Tim Hudson <<a href="mailto:tjh@cryptsoft.com" target="_blank">tjh@cryptsoft.com</a>> said:<br>
<br>
> Semantic versioning is about a consistent concept of version handling.<br>
> <br>
> And that concept of consistency should be in a forms of the version<br>
> - be it text string or numberic.<br>
> <br>
> That you see them as two somewhat independent concepts isn't<br>
> something I support or thing makes sense at all.<br>
<br>
In that case, we should probably just thrown away<br>
OPENSSL_VERSION_NUMBER and come up with a different name. If we keep<br>
that macro around, it needs to be consistent with its semantics as<br>
we've done it since that FAQ update. Otherwise, I fear we're making<br>
life much harder on those who want to use it for pre-processing, and<br>
those who want to check the encoded version number.<br>
<br>
I do get what you're after... a clean 1:1 mapping between the version<br>
number in text form and in numeric encoding. I get that. The trouble<br>
is the incompatibilities that introduces, and I'm trying to take the<br>
middle ground.<br>
<br>
> Our users code checks version information using the integer representation and it should be in<br>
> semantic form as such - i.e. the pure numeric parts of the semantic version.<br>
> <br>
> This is the major point I've been trying to get across. Semantic versioning isn't about just one<br>
> identifier in text format - it is about how you handle versioning in general. And consistency is its<br>
> purpose.<br>
<br>
Sure.<br>
<br>
Would you mind writing up a quick proposal on a new encoding of the<br>
version? (and just so you don't limit yourself too much, it's fine by<br>
me if that includes abandoning the macro OPENSSL_VERSION_NUMBER and<br>
inventing a new one, a better one, with a definition that we can keep<br>
more consistent than our current mess)<br>
<br>
Cheers,<br>
Richard<br>
<br>
-- <br>
Richard Levitte <a href="mailto:levitte@openssl.org" target="_blank">levitte@openssl.org</a><br>
OpenSSL Project <a href="http://www.openssl.org/~levitte/" rel="noreferrer" target="_blank">http://www.openssl.org/~levitte/</a><br>
_______________________________________________<br>
openssl-project mailing list<br>
<a href="mailto:openssl-project@openssl.org" target="_blank">openssl-project@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-project" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-project</a><br>
</blockquote></div>