[openssl-project] Release strategy updates & other policies

[Matt Caswell]

On 26/09/18 18:24, Viktor Dukhovni wrote:
> 
> 
>> 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.

Yes. This is a consequence of going with semver that I don't see any way
of avoiding. At least not without a radical shift in the way we support
releases.

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

If I'm reading you correctly then you seem to be suggesting that we
avoid the semver rules through some clever slight-of-hand based on
conditional macros, i.e. we add new accessors into PATCH releases, but
we hide them away behind a conditional macro.

It means, effectively, that people cannot rely on the semver versioning
if they happen to be using those macros. This seems to make the whole
exercise utterly pointless in my mind. Either we go with semver and
totally commit to it - or we stick with what we've already got. No
half-way, "well we're kind of doing semver, but not really".


Matt