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