[openssl-project] Release strategy updates & other policies

[Matt Caswell]

On 25/09/18 13:25, Richard Levitte wrote:
> In message <e63b557d-0f66-09fd-7f38-19af60b87446 at openssl.org> on Tue, 25 Sep 2018 12:22:44 +0100, Matt Caswell <matt at openssl.org> said:
> 
>>
>>
>> On 25/09/18 12:12, Richard Levitte wrote:
>>> In message <98774a3e-d127-dcd9-c835-3b359d69b449 at openssl.org> on Tue, 25 Sep 2018 11:53:48 +0100, Matt Caswell <matt at openssl.org> said:
>>>
>>>>
>>>>
>>>> On 25/09/18 11:48, Richard Levitte wrote:
>>>>> You are contradicting yourself.  If we only make new branches for
>>>>> MAJOR version number changes, then it will be allowed to add new
>>>>> functionality in them, because that's allowed with a MINOR version
>>>>> number change.
>>>>
>>>> You misunderstand me. Yes, its allowed that we can under semantic
>>>> versioning rules. I'm saying we shouldn't.
>>>
>>> You're saying that we should only release new functionality (new APIs)
>>> in MAJOR releases?  Mind telling us why?
>>
>> Lets imagine we release version 5.0.0. We create a branch for it and
>> declare a support period. Its an LTS release. This is a *stable*
>> release, so we shouldn't de-stabilise it by adding new features.
> 
> Side note: I would never make a x.0.0 release an LTS.  That's very
> risky business, and considering things like missing accessors and
> stuff, it would be downright stupid.
> 
>> Later we do some work on some new features in master. They are backwards
>> compatible in terms of API so we release it as version 5.1.0. Its got a
>> separate support period to the LTS release.
>>
>> We fix some bugs in 5.0.0, and release the bug fixes as 5.0.1. All fine
>> so far. But then we realise there is a missing accessor in it. Its an
>> LTS release so its going to be around for a long time - we really need
>> to add the accessor. But we *can't* do it!! Technically speaking,
>> according to the rules of semantic versioning, that is a change to our
>> API - so it needs to be released as a MINOR version change. That would
>> make the new version 5.1.0....but we already used that number for our
>> backwards compatible feature release!
> 
> Added accessors is additions to out API, not a change of our existing
> API, let's make that clear.  The choice we can make in the scenario is
> to either release 5.2.0 or 6.0.0.  In my mind, both are viable, but
> for different reasons.

Neither seems viable to me. That would mean you have to add all the
features from 5.1.0 into an LTS release. That can't happen.

Matt



> 
> I understand that your idea of having our release branches based on
> the major releases is what's getting you stuck here, 'cause it
> basically forces you do have everything in one timeline (unless we do
> sub-branches, and uhmmm, just nooooo! m'kay?).  So we would
> essentially have a 5.y.z branch where we would have this straight
> timeline (as an example):
> 
>     5.0.0
>     5.0.1
>     5.0.3
>     5.1.0	(this stops the 5.0.z series)
>     5.1.2
>     5.1.3
>     5.2.0	(this stops the 5.1.z series)
>     ...
> 
> With this type of branch, your scenario is already impossible, 'cause
> you can't release 5.0.1 after 5.1.0 LTS, you'll be forced to release
> 5.1.1, and if you add accessors after that, you could release 5.2.0,
> but that means buh-bye for the idea of the 5.1.0 LTS, 'cause you can't
> make any more patch releases on it.  So yeah, I agree in this case
> that we'd be forced to go to a new major release rather than 5.2.0.
> 
> What you got here is a mixup between branch policy and semantic
> versioning.  It got lost in translation...
> 
> Our current pattern is actually to make new stable branches on minor
> releases.  In that case, it would be perfectly feasible to release
> 5.0.1 after 5.1.0 LTS was released ('cause one is on the 5.0 branch
> and the other on the 5.1 branch), and even to release 5.2.0 with new
> accessors (forming the 5.2 branch).
> 
> So generally speaking, it should still be possible to create new minor
> releases in a branch based on major release, but with the caveat that
> it works like an update of the previous minor release (including its
> patch releases), AND that any LTS release basically stops that branch
> from getting new API added ever again.
> 
> Cheers,
> Richard
>