Julian Foad wrote on Mon, 17 Sep 2018 15:47 +0100:
> Daniel Shahaf wrote:
> > [...] I suspect it won't be uncommon for an svn_x_foo() to be graduated
> > to a stable svn_foo() with little or no incompatible changes to its
> > signature and semantics. In such cases, could we keep the svn_x_*()
> > name around for one minor release cycle, with a warning, in order to
> > provide a smoother upgrade path?
>
> I was wondering about the same. I don't think we should promise to do
> so, although we could do it opportunistically on the occasions when the
> graduating API is in fact totally compatible.
>
Agreed.
> But what for? For the API source-code user, the downstream application
> needs to be keeping up with changes in the experimental API, and this
> change would be easy to follow, and this would just delay when they have
> to do it. So that doesn't seem a good reason.
>
For an API user, if we remove the old symbol name then they *must*
update their source code in order to be able to upgrade to the newer
libsvn. Continuing to provide the symbol for one minor release gives
them more time to upgrade their code.
I was thinking not of client maintainers here, but of sysadmins
installing new libsvn packages and the failure modes of any bindings
scripts they may have. It's one thing to install a new libsvn and get a
new warning on stderr; quite another to install a new libsvn and find
that the script dies with APR_ENOTIMPL until somebody does
s/svn_x_foo/svn_foo/ in the script's source code.
In short, I am saying that _if_ we can provide an API- and ABI-
compatible stub for one release cycle, that would make it easier for
API users to upgrade their calls and/or to support multiple libsvn
versions in parallel.
Does this answer your questions?
Cheers,
Daniel
Received on 2018-09-17 17:12:54 CEST