The consensus seems to be to add the deprecated API to 3.0.
I’ve removed the hold.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 15 Nov 2019, at 10:40 pm, Matthias St. Pierre
> wrote:
>
>
>
> On 14.11.19 20:40, Viktor Dukhovni wrote:
>>> On Nov 14, 2019, at 9:15 AM, Matt Caswell 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
