[openssl-project] Release strategy updates & other policies

Matt Caswell matt at openssl.org
Tue Sep 25 13:51:00 UTC 2018



On 25/09/18 14:30, Richard Levitte wrote:
> In message <adfadfd5-f6b8-5190-40fb-62e0329e276f at openssl.org> on Tue, 25 Sep 2018 14:15:32 +0100, Matt Caswell <matt at openssl.org> said:
> 
>> On 25/09/18 14:09, Tim Hudson wrote:
>>> It would also mean our LTS releases are MAJOR.MINOR - as the PATCH is
>>> the fixes we will apply - so it isn't part of the LTS designation as such.
>>> e.g. 5.0.x would be the marker - not 5.0.0 - so 5.0 in shorthand form. 
>>
>> This is where we disagree. My proposal is that the LTS designation would
>> be 5 (not 5.0.x or 5.0.0). We would continue to do updates as we have
>> done except we would have to classify our changes on the LTS branch as
>> either API affecting (e.g. new accessor) or just a bug fix. If the
>> former then the new version becomes an update to the MINOR number,
>> otherwise it is an update to the PATCH number.
> 
> I *like* the idea of an LTS designation on the major number only.
> However, the rest leaves me utterly confused.  Here, it seems that you
> would allow a 5.1.0 minor update in the v5 LTS branch, and yet, you
> say this when responding to my posting:
> 
> In message <989c8546-78e5-8bae-29d7-c9abf1bf79f1 at openssl.org> on Tue, 25 Sep 2018 14:18:17 +0100, Matt Caswell <matt at openssl.org> said:
> 
>> On 25/09/18 13:25, Richard Levitte wrote:
>>> 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 think I need an example timeline from you, 'cause I can see clearly
> how you look at it...

The above was in response to my example of the problem that happens if
you have multiple branches associated with a single MAJOR version
number. In my example 5.0.0 was an LTS release, and 5.1.0 was some other
feature release. The problem was that, in that scenario, if you need to
add an accessor to the LTS release, you can't do it because 5.1.0 is
already used for some other feature release. You can't just call it
5.2.0 and that's the new incarnation of the LTS release because that
means adding all the features from 5.1.0 into the LTS release in the
middle of the LTS cycle.

I see all MAJOR versions as stable releases with a one-to-one
correspondence with a branch. A timeline might look like this


5.0.0
5.0.1 (bug fix)
5.1.0 (add accessor)
                       6.0.0 (new feature)
                       6.0.1 (bug fix)
5.1.1 (bug fix)        6.0.2 (bug fix)
5.2.1 (add accessor)
                       6.1.0 (add accessor)

And so on.

Matt


More information about the openssl-project mailing list