So, after pretty careful consideration, I think I'm -0 on separating out
the bindings, for the reasons:
* Unlike cvs2svn, the bindings are in the same class of functionality
as another major part of the Subversion distribution (namely, the C
language library). It would be odd to say, "if you want to write a C
program using Subversion functionality, you need Subversion; if you want
to write a Python program using Subversion functionality, you need
Subversion plus this add-on."
* As a general rule, when two projects need to be kept in absolute
sync as far as releases, that's a good clue that they shouldn't be two
separate projects. (Either that, or the project should be exploded into
a release for each library and each program. That would be pretty
extreme for us, though.)
* All the reasons for separating out the bindings are about the
developers. There are going to be a lot more consumers of Subversion
than developers; it is worth a moderate amount of inconvenience to us to
save a small amount of inconvenience to consumers.
* Some of the reasons for separating out the bindings are based on
short-term factors, particularly the amount of noise they generated
during the 1.0 release project. As the bindings become more mature,
those reasons will fade.
That said, I don't think separating out the bindings will make them
fail. I just don't think it's the right thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 23 05:21:51 2004