[openssl-project] Release strategy updates & other policies

[Richard Levitte]

In message <20180926165825.GA14262 at roeckx.be> on Wed, 26 Sep 2018 18:58:26 +0200, Kurt Roeckx <kurt at roeckx.be> said:

> On Tue, Sep 25, 2018 at 08:13:53PM +1000, Tim Hudson wrote:
> > On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell <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>> 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.
> 
> We might need to add this to multiple branches at the same time.
> 
> Assume that we have a 2.0.5 and 2.1.2 version. And in both
> versions we need to add that a new function, what should the
> new versions be? My understanding is that you can't actually do
> it.

If we have both 2.0.5 and 2.1.2 as current releases, then it means
we've branched at MINOR releases, i.e. we have a 2.0.x branch and a
2.1.x branch.  Semver says that when you add new functionality, the
next release MUST get its MINOR version number increased.  Since the
last MINOR release is 2.1.0, it means that we must release 2.2.0, and
start a new branch for 2.2.x.

If we branch on MAJOR releases, then that situation isn't even
possible, you just cannot have 2.0.5 and 2.1.2 at the same time...
unless you sub-branch, an endeavour I was stand very far away from.

Cheers,
Richard

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