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
