[openssl-project] Release strategy updates & other policies

[Tim Hudson]

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.

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.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180925/d0dbeac9/attachment.html>