> -----Original Message-----
> From: Branko Čibej [mailto:br...@xbc.nu] On Behalf Of Branko Cibej
> Sent: woensdag 13 april 2011 11:48
> To: Julian Foad
> Cc: dev@subversion.apache.org
> Subject: Re: 1.7 Roadmap Items Evaluation
>
> 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.
>
> Specifically, no library should be using svn_ver_check_list, but only
> svn_ver_equal, if what you say about library compatibility is true.
Our own code should use svn_ver_equal and third party code (which should only
use public apis) should use svn_ver_check_list.
Bert
