[openssl-project] Release strategy updates & other policies

[Richard Levitte]

In message <dee8621c-7071-4bf3-3ce0-dadaff9df682 at openssl.org> on Tue, 25 Sep 2018 11:30:39 +0100, Matt Caswell <matt at openssl.org> said:

> 
> 
> 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.

Most of all, it may mean more frequent MINOR releases.

> 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).

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.

I understand the wish to reduce the number of branches to maintain, we
must just make sure we know what we're talking about.

If we would start branching MAJOR releases only, then we'll need some
kind of policy on what branches are still being developed (i.e new
MINOR releases are allowed in that branch) and what branches are in
maintenance mode only (i.e. only new PATCH releases allowed).

On the other hand, that would simplify our view of 'master', that will
always be the development of the next major release, which I would say
is a good thing, that will reduce the number of PRs just hanging on
github, waiting for us to decide that we switch master to "next major
release development".

So a generic idea could be that:

- master is always the development of next MAJOR release
- the last current MAJOR release branch can have new functionality
  added, i.e. can have new MINOR releases.
- the second, third etc MAJOR release branch is maintenance only.

>From a version number perspective, this will lead to much more rapid
development (good thing in my mind), and a reduction of MINOR release
branches to maintain (hooray!!!).

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/