Hi Karl,
kfogel@collab.net wrote:
>Chia-Liang Kao <clkao@ayer.elixus.org> writes:
>
>
>>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.
>>
>>
>
>Let's see what the state of the bindings is after any core changes
>(especially API changes) have been merged into the 1.0 branch, then.
>
>
For the recent api changes by Tobias and Mike, I already know that they
will break the javahl bindings.
>I'm not trying to ship with broken bindings, don't worry :-). But I
>do want to avoid auto-approving bindings commits. Bindings changes
>still need review, and I don't think we should exempt them from the
>1.0 voting process.
>
>When the time comes, each binding commit can say something like
>
> "This brings the bindings up-to-date with rXXXX, which was merged
> into 1.0 in rYYYY."
>
>That way people will know that this bindings change is a necessary
>consequence of some already-approved API change.
>
>
does that mean if the core changes have been merged into the 1.0 branch,
that I just can merge my changes too?
Or if the discussion about merging a change starts, I comment by saying,
please look at my depending change to?
>-Karl
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 07:24:16 2003