[openssl-project] Release strategy updates & other policies

[Matt Caswell]

On 25/09/18 11:13, Tim Hudson wrote:
> On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
>     On 25/09/18 10:58, Tim Hudson wrote:
>     > On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte
>     <levitte at openssl.org <mailto:levitte at openssl.org>
>     > <mailto:levitte at openssl.org <mailto:levitte at openssl.org>>> wrote:
>     >
>     >     So what you suggest (and what I'm leaning toward) means that
>     we will
>     >     change our habits.
>     >
>     >
>     > Adoption of semantic versioning will indeed require us to change our
>     > habits in a number of areas - that is the point of having a single
>     clear
>     > definition of what our version numbers mean.
>     >
>     > I also do think we need to document a few things like what we mean by
>     > bug fix compared to a feature update as there are items which we could
>     > argue could either be a PATCH or a MINOR update depending on how we
>     > describe such things.
> 
>     Sometimes we need to add a function in order to fix a bug. How should
>     this be handled? e.g. there are 60 functions defined in
>     util/libcrypto.num in the current 1.1.0i release that weren't there in
>     the original 1.1.0 release.
> 
> 
> 
> In semantic versioning those are MINOR releases. The API has changed in
> a backward compatible manner.
> They cannot be called PATCH releases - those are only for internal
> changes that fix incorrect behaviour.
> If you change the API you are either doing a MINOR or a MAJOR release.
> 
> Now I think the flexibility we added during 1.1.0 when the MAJOR change
> was to make APIs opaque was a different context where our API remained
> unstable (in semantic terms) yet we did a release (for other reasons).
> Under semantic versioning, 1.1.0 would have been called 2.0.0 and we
> would have had to batch up the accessor API additions into a 2.1.0
> release and not have those included in any 2.0.X PATCH release.
> 
> It is quite a change under semantic versioning in some areas as it
> basically requires the version to reflect API guarantees. 

I don't think we should batch up accessor API additions. Or in fact any
others. We should release them at the right time as we do now. A move to
semantic versioning shouldn't change that. That has implications for the
way we manage branches and support periods/LTS.

I suggest that we only create new branches for a MAJOR version number
change. We define the support periods/LTS status relative to the major
version number. For a given supported major version we may update the
MINOR or PATCH number at any time dependent on whether we've added any
new functions or not. What we now think of as a "letter" release could
be either a MINOR or a PATCH release under semantic versioning
(dependent on what we've changed/added). We continue with the same
policy of not adding new features to a stable branch (except where
necessary to fix a bug).

Matt