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

Re: Merge policies regarding bindings

From: Ben Reser <ben_at_reser.org>
Date: 2003-12-19 08:59:22 CET

On Thu, Dec 18, 2003 at 11:09:20PM -0800, Justin Erenkrantz wrote:
> As a user, I'd be mad if my Perl code bound against 1.0.5 doesn't work in
> 1.0.6 because we have separate rules for the bindings that allow breakage.
> I think our users should expect that applications written against *any*
> bindings (C, Perl, Python, Java) distributed in the 'official' 1.0 should
> work for all of 1.0. This is where I think we start to define when/how we
> bump SVN versions as a whole. I'd really like to see a discussion on what
> changes are going to merit bumps. What does a schema change mean?
> Protocol change? Core API change? I'd like to have those defined and
> public soon-ish. -- justin

If that's the case we can't do a 1.0 yet. The perl bindings as they
exist now are simply not complete. Until clako and I get them to a
point where pertty much everything is implemented there's no way we can
say for sure that things won't have to change.

I'd like to have the client side stuff done before 1.0 and I'm working
my butt off to try and get that done. If it will be accepted or not I
can't say. But I can tell you already that what's in 0.35.0 won't be
very useful to most people.

I think the reasonable thing to do is specify which bindings are up to
snuff enough to be considered stable. I think the javahl stuff sounds
like it might be... maybe the python bindings. The rest should be made
clear that they aren't stable yet.

Ben Reser <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 Dec 19 09:01:13 2003

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.