[openssl-project] Release strategy updates & other policies

[Kurt Roeckx]

On Wed, Sep 26, 2018 at 07:06:18PM +0200, Richard Levitte wrote:
> 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.

2.0.5 could for instance be something like the current version 1.0.0e,
and 2.1.2 the current 1.0.1b.

So 2.0.5 can't get fixed, because we can't give it a new number?

Does that then mean we should leave numbers free, so that it's
possible we can use them later? And that 2.1.2 should have been
named something like 2.10.2 instead?

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

So you're saying we should always increase the major number, not
the minor number, in case we make a release with new features?
Minor numbers are in case we need to add new features to an older
version?


Kurt