Deprecations

[Matt Caswell]

On 21/02/2020 19:45, Matthew Lindner wrote:
> As a user I'm strongly in favor of this. It gives an example of how
> to implement something using the new interfaces. Even in 1.1.1 there
> are things that are impossible to implement without using low level
> interfaces. The applications should be guides on how to correctly
> implement something and will point out interface deficiencies. 3.0.0
> should not ship with deprecated code in the apps (and 1.1.1 should
> stop using deprecated code in its apps).

As I mentioned in my earlier post I don't believe that this is feasible:

- In some cases an API has been deliberately deprecated with no
replacement. This functionality is also deprecated and will eventually
be removed from the app at the same time that the deprecated API is removed.

- In the case of the speed app, the whole point of some functionality is
to test the speed of the deprecated API. When the deprecated APIs go, so
will that functionality from speed.

- In other cases whole apps are deprecated in favour of a different one
that does the same job. The deprecated app will be kept around until the
deprecated APIs they use are removed, and then the app will also be
removed. Application authors looking for an example should refer to the
non-deprecated alternative app.

For all of the above reasons there will have to be some deprecated APIs
still being used in the apps in 3.0. Any uses that remain are expected
to be removed at the same time as the APIs themselves are removed.

Matt


> 
> - Matthew Lindner
> 
>> On Feb 21, 2020, at 12:06 AM, Kurt Roeckx <kurt at roeckx.be> wrote:
>> 
>> EXTERNAL MAIL: openssl-project-bounces at openssl.org
>> 
>> Hi,
>> 
>> We seem to be deprecating a lot of the old APIs, which I think is a
>> good thing. But I think we might either be deprecating too much, or
>> not actually using the alternatives ourself.
>> 
>> In the apps, a lot of the files define OPENSSL_SUPPRESS_DEPRECATED,
>> which I think is the wrong way to do it. We should stop using the
>> deprecated functions ourself. If there is no way to do this using
>> non-deprecated functions, the function should probably not have
>> been deprecated in the first place.
>> 
>> The apps might have functionality that we want to deprecate too, 
>> that depends on the deprecated functions. In which case we should 
>> also mark that as deprecated, and the apps should always build in 
>> no-deprecation mode.
>> 
>> We might also be deprecating APIs that we don't use ourself, so 
>> it's harder to know if there are alternatives for it.
>> 
>> It would also be nice that if you deprecate a function, that you 
>> point to the alternative way to do the same thing in the manual.
>> 
>> 
>> Kurt
>> 
>> 
>