On 14.02.20 08:24, Tomas Mraz wrote:
I do not understand the pushback too much - Perhaps it could be resolved by proper explanation that deprecation does not mean a removal? Also even if some stuff deprecated in 3.0 is removed in 4.0, it does not necessarily mean that engines must be removed in the same release. They can continue to be supported (just deprecated) until 5.0 for example. I think that doing the deprecation as early as possible is better - it properly gives the signal that the engine interface is legacy and it will disappear at some point. It provides more time for 3rd party engines to transform into providers.
I agree with Tomas. In addition, I think it is high time to publish a definite timescale for actually *removing* the older deprecated APIs, at least for the first three entries in the list below: OPENSSL_NO_DEPRECATED_0_9_8 # OPENSSL_NO_DEPRECATED_1_0_0 # OPENSSL_NO_DEPRECATED_1_0_1 # OPENSSL_NO_DEPRECATED_1_0_2 OPENSSL_NO_DEPRECATED_1_1_0 OPENSSL_NO_DEPRECATED_1_1_1 OPENSSL_NO_DEPRECATED_3_0 Because deprecation without removal is futile, it increases complexity of the code instead of reducing it. Matthias
