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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1098250
Received on 2009-02-03 20:59:57 CET