No objections here so I marked the roadmap item "Deferred" and green in r1135058.
- Julian On Fri, 2011-06-10 at 11:48 -0400, C. Michael Pilato wrote: > On 06/10/2011 11:38 AM, Hyrum K Wright wrote: > > On Fri, Jun 10, 2011 at 10:33 AM, C. Michael Pilato <cmpil...@collab.net> > > wrote: > >> On 06/10/2011 07:39 AM, Daniel Shahaf wrote: > >>> Julian Foad wrote on Fri, Jun 10, 2011 at 11:17:11 +0100: > >>>> The consensus seemed to be [1] that we can add/remove/change private > >>>> APIs during the 1.7.x series, > >>> > >>> Indeed that's the consensus I have sensed. I am not sure if we include > >>> the svn* clients in this "upgrade en bloc" group, but Philip's recent > >>> work on "1.6 client, 1.7 libraries" does highlight one reason for > >>> wanting to minimize the use of private APIs in the svn* tools. > >> > >> I would be in favor of a policy that explicitly disallows our binaries from > >> using private libraries. I believe it would serve to force us to think a > >> bit more globally in terms of what would be useful to expose for the > >> benefit > >> of other clients. > > > > Certainly, but some class of APIs deserves to be private, in my > > opinion. Our SQLite wrappers, for instance, are used throughout > > Subversion, but have no business being exposed outside of it. Nobody > > needs to use them, and exposing them would cause an unneeded > > maintenance burden in the future. > > Sure. I'm not opposed to private APIs. Far from it! But if we're in a > situation where the code in *"subversion/svn/"* needs to be calling directly > into our SQLite wrappers, chances are good that we've royally failed in our > API design, wouldn't you say? > > I should clarify my previous statement though. There are some private APIs > that exist solely for code shared between our command-line clients. > svn_opt_private.h, svn_cmdline_private.h, etc. I certainly have no > objection to our command-line clients using that code. But I'm leery of any > use of svn_wc_private.h, svn_client_private.h, etc. in those tools. Those > could be red flags for API design failures. > > So, in light of the above, I recognize that such a policy statement wouldn't > be quite as easily worded. So much for "easy".
