#10388

[Dr Paul Dale]

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 <Matthias.St.Pierre at ncp-e.com> wrote:
> 
> 
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20191116/e66ad68e/attachment-0001.html>