Deprecations

[Matt Caswell]

On 21/02/2020 20:33, Matthew Lindner wrote:
> I think any deprecated apps or options that must be kept and not
> implemented in the new interface should print a warning when used in
> that case then, and only do that when it's impossible to implement it
> in the current release.

I agree with this. We already do that if you use a deprecated
application. I'm not so sure we've been quite so careful with the
deprecated options, so we should check that.

> 
> That's not at all clear with the speed app for example. (That speed
> app was deprecated I just found out in this email thread.)
> 
That's not actually what I said. The speed app itself is not deprecated.
There are options to the speed app, which are deprecated. Its quite
possible we don't print a warning for those - which we should do.

Matt



> - Matthew Lindner
> 
>> On Feb 21, 2020, at 12:14 PM, Matt Caswell <matt at openssl.org>
>> wrote:
>> 
>> EXTERNAL MAIL: openssl-project-bounces at openssl.org
>> 
>> 
>> 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
>>>> 
>>>> 
>>> 
>