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".
I can't find anything relevant in 'Hacking' ('Community Guide'). That
and the email referenced above only talk about "the libraries" as a
group.
> Specifically, no library should be using svn_ver_check_list, but only
> svn_ver_equal, if what you say about library compatibility is true.
The svn_ver_compatible() / svn_ver_check_list() / svn_ver_equal() APIs
are only used where we are loading optional libraries (FS, RA and
authz).
The other libraries have no version checks explicitly coded into them as
far as I can see. I assume therefore that the version compatibility
rules are defined by our policy (and to some limited extent enforced by
code), not that there are no restrictions to mixing libraries of
different versions beyond what is enforced in code.
But I'm no expert in versioning or what we may have decided in the past.
(I couldn't find any relevant emails with a quick bit of Googling.)
- Julian
Received on 2011-04-13 12:18:29 CEST