[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: API review for 1.11; do we need to mark new APIs as experimental?

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 17 Sep 2018 12:46:42 +0000

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.


Received on 2018-09-17 14:46:53 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.