[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: Patrick Mayweg <mayweg_at_qint.de>
Date: 2003-12-18 07:26:08 CET

Chia-Liang Kao wrote:

>The point I have is:
>* The bindings changes should not bring extra burden to release manager or
> other project members.
>* Merging such changes make the maintainer easier to support the bindings
> as that makes bindings more more current upon release.
>So perhaps the bindings maintainer should just have one-round merging request
>at a certain point before release to minimize the effort of the release manager.
Thats a good idea.

>On Wed, Dec 17, 2003 at 02:17:39PM -0600, kfogel@collab.net wrote:
>>And will rushing in a bunch of commits at the last minute make the
>>bindings as complete as they should be for a 1.0 release? :-)
The only problem I see, are API changes in the core which are merged
into the branches without the matching patches for the bindings. That
will unneccesary break the bindings. These revisions should be
considered together. I am working realy busy to keep in sync with the
recent api-changes of Tobias and Mike.

I would be great if the core developers would put a notification line
when they change the svn_client_* interfaces into their log messages.
Tobias put one into his recent commits. It makes it much easier for me
to notice.

Given that I see the javahl bindings a thin layer over the svn_client_*
calls, I think that they are as complete as they can be ;-) .

>>I think the bindings commits should be treated the same way as any
>>other commit, as far as the 1.0 release branch goes.
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 18 07:26:50 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.