[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