[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Moving bindings into a separate project.

From: <kfogel_at_collab.net>
Date: 2004-02-20 20:30:42 CET

Ben Reser <ben@reser.org> writes:
> I think we'd have a subversion-swig-bindings-1.0.x.tar.gz package.
> Other then that there's the javahl bindigs and com bindings.
> Only the former seems to be maintained. The java swig bindings don't
> seem to be maintained either. I think we should delete the bindings
> that aren't being maintained and put a place holder like the ruby
> bindings. If someone wants to resurrect them they can always cp the old
> versions and start working on them again.
> So really that means we're down to perl, python and javahl bindings. We
> could probably easily release those as separate tarballs. We could have
> a directory in our repo for the shared files and use svn:externals to
> pull it in..

Let's not conflate "maintained/unmaintained" with "swig/non-swig". A
particular bindings layer could fall anywhere in the 2x2 matrix
defined by those categories.

I think it makes sense for subversion-bindings-X.Y.Z.tar.gz to include
any bindings that work for X.Y.Z. Unmaintained bindings probably
won't work, so of course they shouldn't be shipped. Of the bindings
that are maintained, a user doesn't really care whether they used SWIG
to do it or not (except that they had to get SWIG installed, which is
a one-time thing, or N-time for slow-growing N). They just want their

If later it looks like several different bindings packages are needed,
you can divide them up then. To start with, I think just one is the
simplest way to go, though.

> I don't know there are several ways to handle this. We just need to put
> our heads together and figure out what makes the most sense.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 20 21:33:19 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.