On Mon, Feb 14, 2011 at 12:30, Stefan Sperling <s...@elego.de> wrote: > On Mon, Feb 14, 2011 at 06:44:21PM +0200, Daniel Shahaf wrote: >> The 1.6.x-svn_fs_commit_txn branch adds a new Subversion-private API. >> >> On the one hand, if we add a new private API to 1.6.16, then clients >> compiled against 1.6.16 will fail if run with 1.6.15 present in runtime. >> (svn_ver_compatible() doesn't compare the patch number, only the >> major/minor numbers.) Â Consequently, adding this API might break >> 1.6.16->1.6.15 downgrading, which (last I check) we promise to work. >> >> On the other hand, we have precedent for adding new private API's in >> patch releases (attached). >> >> Thoughts? Â Should or shouldn't we add Subversion-private API's in non-.0 >> releases? > > The safest strategy is probably to backport these APIs as static > functions within the files that need them. > > I know there is precedent for adding new functions to include/private > and using those from the CLI client (I've done this myself). But it's > not a good idea for the reason you stated: the svn binary compiled against > 1.6.16 should be able to run against 1.6.15 libraries. Else we risk breaking > someone's setup when they decide to revert to an earlier release. > In practice, people will most likely always downgrade the svn client > together with the libraries, but we cannot be sure...
Agreed. And think about static binaries. The short answer is that the shared-libraries/DLLs have a *different* binary API. And that is explicitly forbidden according to our versioning rules. Cheers, -g