[openssl-project] Release strategy updates & other policies

Matt Caswell matt at openssl.org
Tue Sep 25 13:11:11 UTC 2018



On 25/09/18 13:54, Richard Levitte wrote:
> In message <896ece72-8923-801e-b97d-5a1b21c9c815 at openssl.org> on Tue, 25 Sep 2018 13:37:45 +0100, Matt Caswell <matt at openssl.org> said:
> 
>>> And that is what semantic versioning is about - it is about the API.
>>> So if you add to the API you change either MINOR or MAJOR.
>>> 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.
>>> You don't get to make API changing releases that expand the API behind
>>> the existing releases that are out there.
>>
>> Exactly. That is why I am proposing that each time we create a branch it
>> is associated with a major release ONLY. You can't have two branches
>> with the same major release because that means you cannot make MINOR
>> changes on the older branch - even ones that we would historically have
>> allowed.
> 
> Hmmmm?  If we have three major branches 5.0.0, 6.0.0 and 7.0.0, I
> don't quite see what would stop us, technically.

Is this exactly what I'm proposing? There is no problem if each major
release is associated with a different branch. The problem comes if
there are two branches on the SAME major version.

Matt

> 
>     5.0.0
>     5.0.1
>     5.1.0
>     5.1.1
>            6.0.0        (new branch)
>            6.0.1
>            6.0.2
>                   7.0.0 (new branch)
>            6.0.3
>            6.1.0
>     5.1.2
>                   7.0.1
>                   7.1.0
>     5.2.0
>            6.1.2
>            6.2.0
> 
> Nothing in major based branching stops this from happening.  The only
> thing you stop is new patches on the next to last minor release in any
> given branch.
> 
> Cheers,
> Richard
> 


More information about the openssl-project mailing list