<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Sep 25, 2018 at 9:22 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">Lets imagine we release version 5.0.0. We create a branch for it and<br>
declare a support period. Its an LTS release. This is a *stable*<br>
release, so we shouldn't de-stabilise it by adding new features.<br>
<br>
Later we do some work on some new features in master. They are backwards<br>
compatible in terms of API so we release it as version 5.1.0. Its got a<br>
separate support period to the LTS release.<br>
<br>
We fix some bugs in 5.0.0, and release the bug fixes as 5.0.1. All fine<br>
so far. But then we realise there is a missing accessor in it. Its an<br>
LTS release so its going to be around for a long time - we really need<br>
to add the accessor. But we *can't* do it!! Technically speaking,<br>
according to the rules of semantic versioning, that is a change to our<br>
API - so it needs to be released as a MINOR version change. That would<br>
make the new version 5.1.0....but we already used that number for our<br>
backwards compatible feature release!<br></blockquote><div><br></div><div>And that is what semantic versioning is about - it is about the API.</div><div>So if you add to the API you change either MINOR or MAJOR.</div><div>In your scenario the moment you need to add an API you are doing a MINOR release and if you already have a MINOR release under the MAJOR then you need to add a MINOR on top of the latest MINOR that you have.</div><div>You don't get to make API changing releases that expand the API behind the existing releases that are out there.</div><div><br></div><div>That is not how a semantically versioned project behaves.</div><div><br></div><div>The rules are strict for a reason to stop some of the practices that we have - where PATCH releases add APIs. </div><div><br></div><div>Part of the precondition for a semantically versioned project is that the API (and in this sense this is the public API) is under "control" as such. </div><div><br></div><div>I think there are very few circumstances under which we have needed to add APIs - and I think outside of accessor functions during the opacity changes - I don't know that there were any API additions that weren't actually avoidable by solving the problem without adding an API. I don't know - I haven't checked - but none leap to the front on mind. We have done that simply because we didn't have a strict rule in place about API additions - we do about changes or deletions - but we tend to view additions as relatively safe (and they are from a backwards compatible perspective - but they are not from a semantic versioning point of view). </div><div><br></div><div>Tim.</div><div><br></div></div></div>