Re: Merge policies regarding bindings

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.

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.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 18 17:20:59 2003