<div dir="ltr"><div dir="ltr">Hello,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale <<a href="mailto:paul.dale@oracle.com">paul.dale@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">There is some pushback against the deprecations going on in various PRs.<div><br></div><div>The plan has always been to deprecate engines in 3.0 and removing support for them 5+ years later.  Originally, the path was to have included an engine provider that could load engines and make them appear to be a provider.  After a fair amount of investigation, this was deemed to be too difficult in the 3.0 time frame.</div><div><br></div><div>Do we still want to deprecate engines in 3.0?</div><div>Should we defer until 4.0 instead?</div></div></blockquote><div><br></div><div>I think we should delay the deprecation of engine stuff to 4.0. Personally I don't have sense of stability of provider API.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>The main benefits seem to boil down to continuing to support existing engines vs removing the legacy code paths and switching to the provider model.<br></div></div></blockquote><div><br></div><div>For me, both as open-source and commercial engine developer seems reasonable to delay conversion from engines to providers at least until 3.0.0 feature freeze happens.</div><div>But some features I'm interested in imply engine model (and it will be great if somebody else could look at PR 10904 to avoid it when possible).</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>