Deprecations

[Matthew Lindner]

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).

- 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
> 
>