Re: [openssl-project] Release strategy updates & other policies

2018-09-28 Thread Tim Hudson
On Fri, Sep 28, 2018 at 4:55 PM Matt Caswell  wrote:

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

+1

I see no point in changing what we are doing *without* getting the benefit
of following the semantic versioning approach.
Right now things like 1.1.0 with a major API change and 1.1.1 with a major
feature update of TLSv1.3 are confusing to those who haven't been along for
the journey.

Our current handling of version numbering surprises developers and requires
careful explanation.

Tim.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Release strategy updates & other policies

2018-09-28 Thread Matt Caswell



On 26/09/18 18:24, Viktor Dukhovni wrote:
> 
> 
>> On Sep 25, 2018, at 9:51 AM, Matt Caswell  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
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project