[Rivet] boost.m4 BOOST_FIND_LIB

[James Monk]

On 16 Jul 2013, at 15:32, Andy Buckley wrote:

> Anyway, the general point is that we should review changes to the API
> carefully rather than just dropping them in -- we have a lot of users
> now, so should avoid flip-flopping the interface design in-between every
> release. And I also need to learn a bit more about how best to work with
> feature development branches in hg/git!

Absolutely - I had not intended the tagging additions to the API to end up in the main trunk just yet.  What threw me was I thought the tagging feature was safely encapsulated in its own branch (as was the gzip stuff), when in fact the tagging stuff was in a clone of the main default branch, so when it got pushed it went on the main default.  Having a clear statement on when to use clones and when to use branches (and why!) would be pretty useful to me.  

In fact, if we want to freeze development for 2.0.0 then would it make sense if there was a 2.0.0 release candidate branch (probably from Frank's previous commit?), which would allow general development to continue on the trunk, rather than having a panoply of different development clones/branches for each new feature?

cheers,

James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.hepforge.org/lists-archive/rivet/attachments/20130716/1b567827/attachment.html>