#10388

[Matthias St. Pierre]

On 14.11.19 20:40, Viktor Dukhovni wrote:
>> On Nov 14, 2019, at 9:15 AM, Matt Caswell <matt at openssl.org> wrote:
>>
>> "No existing public interface can be removed until its replacement has
>> been in place in an LTS stable release. The original interface must also
>> have been documented as deprecated for at least 5 years. A public
>> interface is any function, structure or macro declared in a public
>> header file."
>>
>> So the functions we're talking about don't yet have a replacement -
>> there will be one in 3.0. So presumably they will be documented as
>> deprecated in 3.0. So we have to support them for at least 5 years from
>> the release of 3.0.
> I think that when we're deprecating an entire family of *related* accessors
> (for the same structure) that have been in place for some time, the addition
> of a missing member of that family is reasonably interpreted as not resetting
> the support clock on the entire family.  We can still remove them all as though
> the missing members of the family had been in place all along.
>
> That is, we should (and if that requires a policy update and vote so be it) be
> able to interpret the rules based on the "spirit" (intent) without getting
> unduly burdened by the "letter", where common sense would suggest that we're
> getting the intended outcome.

I don't think we need a reinterpretation, or even a change, of the existing policy for
this specific case,  since already now the *entire* engine api can only be deprecated
in version 3.0 and removed afterwards according to the policy cited by Matt.

We can simply add the missing accessor as bugfix to 1.1.1 and 3.0, and immediately
deprecate it on the latter. The only difference will be that we end up with n+1 deprecated
functions instead of n  (for some natural number n) for version 3.0.

Even after 3.0 is released and as long as 1.1.1 LTS is still supported, we can proceed
in the same way without violating existing policies.


Matthias