[openssl-project] Release strategy updates & other policies

[Kurt Roeckx]

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.


Kurt