[openssl-project] Release strategy updates & other policies

[Viktor Dukhovni]

> On Sep 25, 2018, at 9:51 AM, Matt Caswell <matt at openssl.org> wrote:
> 
> 5.0.0
> 5.0.1 (bug fix)
> 5.1.0 (add accessor)
>                       6.0.0 (new feature)
>                       6.0.1 (bug fix)
> 5.1.1 (bug fix)        6.0.2 (bug fix)
> 5.2.1 (add accessor)
>                       6.1.0 (add accessor)

Previously, we could add non-triviall features in "z+1" of "x.y.z",
with a stable ABI moving forward from "x.y.z" to "x.y.(z+1)".

Thus, e.g. 1.1.1 is a feature evolution of 1.1.0.  With this, we seem
to lose the ability to produce a manifestly (forward) ABI-compatible
feature release, that's a drop-in replacement for a previous release.

I would have expected to have 5.1.x as an ABI compatible upgrade of
5.0 with non-trivial new features.

The trivial API updates in stable releases (new accessors for forward
compatibility, ...) would go into the micro version along with the
bug fixes.  And should be made for the same reason.

In the case of new accessors, their visibility should conditioned
the user defining a suitable macro to make them visible.  Their
purpose is to facilitate compiling code that's forward-ported
to a later release, but needs to still work with the stable
release.  Otherwise, there really should be no feature changes
in stable releases.

So, Matt, we're not on the same page just yet...

-- 
-- 
	Viktor.