<br><tt><font size=2>Vish wrote on 05/17/2012 02:18:19 PM:<br>
...</font></tt>
<br><tt><font size=2>> 3 Feature Branch in Core</font></tt>
<br><tt><font size=2>> <br>
> We are doing some work to support Feature and Subsystem branches in
<br>
> our CI system. 3rd party apis could live in a feature branch so that<br>
> they can be tested using our CI infrastructure. This is very similar<br>
> to the above solution, and gives us a temporary place to do <br>
> development until the internal apis are more stable. Changes to <br>
> internal apis and 3rd party apis could be done concurrently in the
<br>
> branch and tested. </font></tt>
<br>
<br><tt><font size=2>can you elaborate on this last sentence?  When
you say "changes to internal</font></tt>
<br><tt><font size=2>apis" do you mean "in general" or only
when in the context of those</font></tt>
<br><tt><font size=2>3rd party APIs needing a change?  I can't see
the core developers wanting</font></tt>
<br><tt><font size=2>to do internal API changes in a 3rd party api branch.
 I would expect</font></tt>
<br><tt><font size=2>3rd party api branches to mainly include just stuff
that sits on top of</font></tt>
<br><tt><font size=2>the internal APIs and (hopefully very few) internal
API tweaks.</font></tt>
<br><tt><font size=2>Which to me means that these 3rd party API branches
should be continually </font></tt>
<br><tt><font size=2>rebased off of the trunk to catch breaking changes
immediately.</font></tt>
<br>
<br><tt><font size=2>If I understand it correctly, of those options, I
like option 3 because </font></tt>
<br><tt><font size=2>then the CI stuff will detect breakages in the 3rd
party APIs right away</font></tt>
<br><tt><font size=2>and not until some later date when it'll be harder
to fix (or undo) those</font></tt>
<br><tt><font size=2>internal API changes.</font></tt>
<br>
<br><tt><font size=2>-Doug Davis</font></tt>
<br><tt><font size=2>dug@us.ibm.com</font></tt>