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.
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
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
