Deprecation

[Dr Paul Dale]

Roumen in https://github.com/openssl/openssl/pull/10977#issuecomment-584818517 <https://github.com/openssl/openssl/pull/10977#issuecomment-584818517>
Dmitry in https://github.com/openssl/openssl/pull/11082#issuecomment-585603911 <https://github.com/openssl/openssl/pull/11082#issuecomment-585603911>
And a further one via private email.

Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 14 Feb 2020, at 7:37 pm, Matt Caswell <matt at openssl.org> wrote:
> 
> 
> 
> On 14/02/2020 02:30, Dr Paul Dale wrote:
>> There is some pushback against the deprecations going on in various PRs.
> 
> I've not followed all of the PRs. Can you point at some specific
> comments you've received pushing back on this?
> 
> Matt
> 
> 
>> 
>> The plan has always been to deprecate engines in 3.0 and removing
>> support for them 5+ years later.  Originally, the path was to have
>> included an engine provider that could load engines and make them appear
>> to be a provider.  After a fair amount of investigation, this was deemed
>> to be too difficult in the 3.0 time frame.
>> 
>> Do we still want to deprecate engines in 3.0?
>> Should we defer until 4.0 instead?
>> 
>> 
>> The main benefits seem to boil down to continuing to support existing
>> engines vs removing the legacy code paths and switching to the provider
>> model.
>> 
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200214/971b2c74/attachment.html>