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

Re: handling bindings changes for 1.0

From: Eric Gillespie <epg_at_pretzelnet.org>
Date: 2004-01-09 04:16:10 CET

> On Thu, Jan 08, 2004 at 04:32:53PM -0600, kfogel@collab.net wrote:
> > Should we abandon the three +1's system for bindings changes on the
> > 1.0 branch?

If i understand clkao correctly, this is what he wanted from the
start. Certainly this is what i've advocated.

So +1 from me.

Ben Reser <ben@reser.org> writes:

> epg voted for the changes in the STATUS file on perl, so I'm
> assuming that he felt comfortable voting on it, but I'm unsure
> of what his experience is with them.

I maintain and use the perl binding on multiple platforms. I
have read the code, and have read and understand the pending

> I'm not convinced there are enough people who are terribly
> familiar enough with the bindings to be casting +1s for things
> on them. At the same time I would love to have them reviewed
> as much is as possible.

Sure, who wouldn't want that? But we don't have it. And keeping
bindings changes out because we are short on qualified reviewers
does not make the older versions on the 1.0 branch superior.

We want to ship the best we have, as decided by those qualified,
however few they may be.

> As I said earlier on IRC I'm not sure what you mean by
> "features."

Greg Stein gave a good definition in that conversation. Features
are anything beyond the raw SWIG binding. Once you have the raw
binding, however ugly or brutish it may be, it is something that
*works*. Everything else is a feature.

> IMHO the bindings should implement as much as the API as we
> possibly can at 1.0 release.


Eric Gillespie <*> epg@pretzelnet.org

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 9 04:15:37 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.