Boost logo

Boost :

From: Pavol Droba (droba_at_[hidden])
Date: 2007-06-03 05:49:55


Phil Richards wrote:
> 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
> library?
>
> *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
> frequently).
>
> 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?
>

As far as I know, the stable branch is there exactly for this purpose.

Trunk will be open to wild development, but only after the changeset is
finished, it will be merged to the stable branch. The stable branch
should always be in "ship-ready" state.

Regards,
Pavol.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk