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

Re: Adding new Subversion-private API's in patch releaqses

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 15 Feb 2011 01:38:51 -0500

On Mon, Feb 14, 2011 at 12:30, Stefan Sperling <stsp_at_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
Received on 2011-02-15 07:39:28 CET

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.