[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 21:10:55 CET

Ben Reser <ben@reser.org> writes:
> 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.

Okay, that makes sense. (I don't consider myself to be more than a
gadfly here -- the current bindings maintainers are the ones who will
have to do the work, so let's hope to hear from more of them soon! :-) ).

> > 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? :)

Seriously, part of the goal here is to not occupy Subversion core
development time with bindings stuff. But of course, what happens
with the bindings after they leave this tree still has to be "good".

However, beyond what I've said so far, I probably don't need to be
much involved (and would only interfere if I stayed). So I'll exit
the thread now. Have a good discussion w/ the other bindings
maintainers. Sometime soon, I'll post back with a date for taking
them out of the svn tree, by which time hopefully y'all will have a
plan ready.

-K

---------------------------------------------------------------------
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:13:47 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.