On Fri, Feb 20, 2004 at 01:30:42PM -0600, kfogel@collab.net wrote:
> 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.
No conflation going on here. This is the way I see the bindings:
Maintianed: perl, python, javahl (i.e. the non-SWIG ones).
Unmaintained: java swig bindings, com bindings
As you can see I've got all spots in the 2x2 matrix filled. :)
> 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
> bindings.
That assumes that the perl bindings are ready at the same rate that all
the other bindings are ready. If we start leaving out bindings that
aren't ready from the tarballs then it's not clear what's in the file.
So that's why my inclination is to have separate tarballs for each
binding.
Plus, what happens if we find bugs in one of the bindings. Do we really
want to release an update for all of them?
Realistically, if it wasn't for the SWIG files, we'd be entirely
separate. I like sharing the SWIG files for efficiencies sake, but I
don't think it's a great idea to force all the bindings to follow the
same schedule.
Especially since the schedule problem is what we're trying to solve.
> 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.
Simple, but does it solve the problem or simply push it out of your
view? :)
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 20 22:03:54 2004