Julian Foad wrote on Mon, 17 Sep 2018 12:36 +0100:
> Branko Čibej wrote:
> > Consequently, releasing experimental features to the stable set implies
> > removing [the experimental API] — and yes, this *will* create ABI
> > incompatibilities. If we decide that we cannot allow that and that ABI
> > compatibility is more important even for experimental stuff, we can keep
> > dummy functions that return APR_ENOTIMPL [...].
>
> Not worth it. A client written against the experimental API is unlikely
> to handle that error gracefully (keeping all other functions working)
How so? A client app written against *any* API needs to be written to
handle unexpected errors returned from that API, due to forward
compatibility (the runtime libraries might be newer than the compile-time
libraries). APR_ENOTIMPL is, at worst, just another not-specifically-handled
err->apr_err value.
I think our choice is between always returning some error code, as
above, and removing the function entirely, in which case the runtime
linker will prevent the application from starting, so the user won't be
able to use even non-experimental functions. As much as I like "If you
have to fail, fail early", bricking an app because a shared library it
depends on was upgraded strikes me as an undesirable outcome.
> unless it is a rather trivial client or was specifically designed and
> *tested* against that scenario.
Cheers,
Daniel
Received on 2018-09-17 14:46:53 CEST