On 25/09/18 13:25, Richard Levitte wrote:
> In message <e63b557d-0f66-09fd-7f38-19af60b87...@openssl.org> on Tue, 25 Sep
> 2018 12:22:44 +0100, Matt Caswell <m...@openssl.org> said:
>> On 25/09/18 12:12, Richard Levitte wrote:
>>> In message <98774a3e-d127-dcd9-c835-3b359d69b...@openssl.org> on Tue, 25
>>> Sep 2018 11:53:48 +0100, Matt Caswell <m...@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.
> 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.1.0 (this stops the 5.0.z series)
> 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.
openssl-project mailing list