Hyrum K. Wright wrote:
> This issue has come up a few times on IRC, but I don't know if we've ever
> discussed it here, so I'm opening this can of worms now: Should the bindings be
> spun off into their own project(s)?
>
> Having the bindings in our tree has its benefits. In the early days of the
> project, having a large binding surface encouraged the use of Subversion as a
> library, and led to increased adoption. By making the swig bindings officially
> supported, users know they can expect a certain quality when they ship with our
> releases. Also, the bindings tests (especially the ruby bindings) provide
> additional test coverage into our APIs, which helps uncover additional bugs.
>
> However, in the last couple of years, it has seemed that shipping the bindings
> with the core libraries has been more of a hindrance than a help. I seem to
> recall more than one occasion where a release was held up because the bindings
> had problems, and a lack of knowledgeable maintainers[1] led to delays. In
> addition to catching bugs, the bindings tests also lead to spurious errors which
> can likewise delay development. The root cause seems to be a lack of
> maintainers, due to Real Life, lack of interest or otherwise. And shipping
> unmaintained code is a Bad Thing: it's better to not ship code than code that is
> full of bit rot.
>
> There are already other projects which maintain bindings for languages we do and
> don't include, such as SharpSvn, SVNCPP, PySVN and others[2]. Should we follow
> their lead and graduate our existing swig and JavaHL bindings into separate
> projects? If we did, here are a few questions:
> * Where would we spin off the bindings to?
> * How much work would be involved in doing this?
> * Should/can it be done for 1.6?
>
> -Hyrum
>
> [1] No offense the the existing bindings maintainers, of course. The developer
> audience for the bindings is simply smaller than that of the core libraries.
> [2] http://subversion.tigris.org/links.html#bindings
I've advocated doing this to various degrees over time. I'm not sure
there's a strong reason to spin them off into their own separate projects,
really. At least, no more so than we have reason to spin off our tools/ or
contrib/ directories. The problem is (and has always been) that the
bindings don't have their own release schedules. The solution seems to me
quite simple -- publish them separately (when they are ready to be
published) or don't publish them at all.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1098301
Received on 2009-02-03 21:05:56 CET