<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25/09/18 10:58, Tim Hudson wrote:<br>
> On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte <<a href="mailto:levitte@openssl.org" target="_blank">levitte@openssl.org</a><br>
> <mailto:<a href="mailto:levitte@openssl.org" target="_blank">levitte@openssl.org</a>>> wrote:<br>
> <br>
>     So what you suggest (and what I'm leaning toward) means that we will<br>
>     change our habits.<br>
> <br>
> <br>
> Adoption of semantic versioning will indeed require us to change our<br>
> habits in a number of areas - that is the point of having a single clear<br>
> definition of what our version numbers mean.<br>
> <br>
> I also do think we need to document a few things like what we mean by<br>
> bug fix compared to a feature update as there are items which we could<br>
> argue could either be a PATCH or a MINOR update depending on how we<br>
> describe such things.<br>
<br>
Sometimes we need to add a function in order to fix a bug. How should<br>
this be handled? e.g. there are 60 functions defined in<br>
util/libcrypto.num in the current 1.1.0i release that weren't there in<br>
the original 1.1.0 release.<br></blockquote><div><br></div><div><br></div><div>In semantic versioning those are MINOR releases. The API has changed in a backward compatible manner.</div><div>They cannot be called PATCH releases - those are only for internal changes that fix incorrect behaviour.</div><div>If you change the API you are either doing a MINOR or a MAJOR release.</div><div><br></div><div>Now I think the flexibility we added during 1.1.0 when the MAJOR change was to make APIs opaque was a different context where our API remained unstable (in semantic terms) yet we did a release (for other reasons).</div><div>Under semantic versioning, 1.1.0 would have been called 2.0.0 and we would have had to batch up the accessor API additions into a 2.1.0 release and not have those included in any 2.0.X PATCH release.</div><div><br></div><div>It is quite a change under semantic versioning in some areas as it basically requires the version to reflect API guarantees. </div><div><br></div><div>Tim.</div><div><br></div></div></div>