Deprecation

[Benjamin Kaduk]

On Fri, Feb 14, 2020 at 05:59:32PM +0100, Tomas Mraz wrote:
> On Fri, 2020-02-14 at 16:17 +0000, Salz, Rich wrote:
> > I think we should delay the deprecation of engine stuff to 4.0.
> > Personally I don't have sense of stability of provider API.
> >  
> > I share this concern.  This is the first release of the provider
> > infrastructure, and while it will be known to work for FIPS modules,
> > it’s hubris to think OpenSSL will get it completely right for other
> > uses.
> >  
> > All other deprecations point to existing API’s or, if they are brand
> > new, are not a lot of code/work to implement them.  The provider
> > interface is both brand new and significant work.  Deprecating and
> > saying “use providers” without at least one release cycle of 
> > providers, seems premature.
> 
> This is an argument for not removing engines in 4.0 (or earlier than
> one major release after the provider interface fully stabilizes and
> proves viable). However I do not think that it is argument for not
> deprecating it. Deprecation is declaration of intent and not a way to
> force people stop using the API immediately.
> 
> How is the provider API going to improve/stabilize, if the 3rd party
> engine suppliers will not get the the message that the engine API is
> eventually going away in future and start writing providers as
> replacement.

I have similar feelings to Tomas.

Note that the current policy's test for "is removal allowed" is a
two-pronged test, and if the next release after 3.0 is 4.0, we would not be
allowed to remove engines in 4.0, since providers (the "engine
replacement") will not have been available in a (previous) LTS release.

If we know that something will need to go away eventually, it seems like we
can use deprecation annotations to publicize that fact, even if the
eventual removal will be delayed for quite some time due to other
considerations.

-Ben