Deprecations

[Matthew Lindner]

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.

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

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