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

Re: 1.7 Roadmap Items Evaluation

From: Blair Zajac <blair_at_orcaware.com>
Date: Wed, 13 Apr 2011 15:28:21 -0700

On 04/13/2011 03:17 AM, Julian Foad wrote:
> Branko Čibej wrote:
>> On 13.04.2011 11:37, Julian Foad wrote:
>>> On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote:
>>>> On 12.04.2011 18:50, Julian Foad wrote:
>>>>> On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote:
>>>>>> On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
>>>>>>> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
>>>>>>>> "Remove temp APIs": I would put this at "nice to have". These APIs are
>>>>>>>> private, so what's the penalty if they wind up in the release?
>>>>>>> We'd have to support them privately for the rest of the 1.7.x line, due
>>>>>>> to private ABI compatibility?
>>>>>>>
>>>>>>> http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849
>>>>>> Ah, okay. I didn't realize that we allowed mix-and-match of
>>>>>> patch-level-differing-only versions.
>>>>> Erm... AFAIK, we don't support a mis-matched set of libraries (e.g.
>>>>> libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have
>>>>> internal APIs that are called from a different Subversion library, and
>>>>> we won't need to preserve those through 1.7.x.
>>>> Then you'd better change the version checking code in the libraries.
>>> Please correct my understanding or ... wait a sec, this is already doc'd
>>> in 'Hacking', so I'll go take a look and correct myself.
>
> Are you saying we *do* support running a mixed set of Subversion
> libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was
> under the impression we had a policy of "you must upgrade (or downgrade)
> the libraries as a complete set, not individually".

That's my understanding too, and IIRC, we've done this in the past with
merges to release branches.

Blair
Received on 2011-04-14 00:28:57 CEST

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.