On 25/09/18 14:21, Richard Levitte wrote:
> In message <aed26fde-117e-04ad-d8e7-df84e257b...@openssl.org> on Tue, 25 Sep 
> 2018 14:11:11 +0100, Matt Caswell <m...@openssl.org> said:
> 
>>
>>
>> On 25/09/18 13:54, Richard Levitte wrote:
>>> In message <896ece72-8923-801e-b97d-5a1b21c9c...@openssl.org> on Tue, 25 
>>> Sep 2018 13:37:45 +0100, Matt Caswell <m...@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.
> 
> It seems I misread you, then.
> 
> The more I think about it, the more I agree with the MAJOR release
> base for our branches, what I still don't quite catch on is your
> thinking around the release on new MINOR releases...  you seem to say
> that they shouldn't be allowed, at least under certain conditions, or
> always, and question is then, what's the actual difference?

Semantic versioning says that a change to your API means the release is
at least MINOR. Or it could be MAJOR.

Up until now we've had a subtly different rule. Adding a new feature
cannot go into a stable release. We *do* however allow some changes to
the API in a stable release, e.g. new accessors, some limited
constifying, error codes etc (see my other email for other examples).
I'll collectively call these things "trivial API changes".

So, the rules would be:

1) Each MAJOR version has a branch associated with it
2) New features only ever get merged to master.
3) When master is eventually released, a new branch is created for it
and it becomes a new MAJOR version.
4) Trivial API changes can go to any branch
5) When creating a new release from a branch, if there have been any
trivial API changes then we update the MINOR version. Otherwise we
update the PATCH version.


Matt




_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Reply via email to