From: Phil Richards (news_at_[hidden])
Date: 2007-06-03 04:30:17
On 2007-06-02, Peter Dimov <pdimov_at_[hidden]> wrote:
> Phil Richards wrote:
> > I would have thought that the obvious(!) thing to do (after the move
> > to subversion, when such thinhgs will be easier) is to say that when
> > there is a breaking change to an interface that other libraries rely
> > on, then that work *must* be carried out on a branch, and that branch
> > is only a candidate for merging back to the trunk when all affected
> > libraries have been updated.
> This will effectively block all breaking interface changes. The affected
> libraries will never be updated if there are no test failures.
I don't think it needs to be quite that extreme - but I take the point.
I suppose my idea ends up requiring that branches have their test
results published so that other people can see the breakages, but that
isn't going to be practical.
Ok, given that this approach is not liked, then *what* approach can be taken
that will not result in weeks (or months) of time in which the SVN trunk is
unable to be shipped because somebody has changed the API to a low level
*Something* other than "dump the API changing break on the trunk and
leave it to get fixed when possible" needs to exist (IMHO, of course).
Otherwise I don't see that boost is going to be in any better position
than it is now (well, not true - such problems should have much less
It would be wonderful to think that such changes could be coordinated
with all library developers so that breakages could be fixed within
days, but, really, is that ever going to be possible?
-- change name before "@" to "phil" for email
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk