On 17/01/2020 10:42, Tomas Mraz wrote:
> On Fri, 2020-01-17 at 10:34 +0000, Matt Caswell wrote:
>>
>> On 17/01/2020 06:31, Dr Paul Dale wrote:
>>>  1. Leave them public and unchanged — that is, don’t deprecate
>>> these two
>>>     functions yet.
>>>  2. Deprecate them and add KDFs to replace them.
>>>  3. Deprecate them, leave them alone and hope they go away
>>> painlessly at
>>>     some point.
>>
>> 2 is really just and extension of 3 - either way we deprecate them.
>> In 2
>> we additionally provide a replacement.
>>
>> I definitely think they *should* be deprecated.
>>
>> Any replacement would necessarily go in the "legacy" provider I
>> think.
>> If a replacement is not difficult I would favour that. But I could
>> live
>> with (2).
> 
> Did you mean (3) here actually?
> 

Sorry - yes - that's what I meant!

I would prefer us to deprecate and add a replacement (option 2). But I
could live with just deprecating (option 3).

Matt

Reply via email to