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
