From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2005-08-16 03:54:13
Rob Stewart <stewart_at_[hidden]> writes:
> From: "AlisdairM" <alisdair.meredith_at_[hidden]>
>> I would be in favour of shorter release cycles though, as new libraries
>> come through the review queue. Regular releases like this would
>> probably keep the mainline more stable avoid some of the problems seen
>> trying to get the last 2 releases out the door.
> That's come up before. The question is how to effect it.
> Library developers need some time to insert new functionality and
> changes to existing functionality between releases. When that
> happens with multitudinous libraries, the compounding of problems
> leads to long release cycles.
> The only thing I can think of to address this is for each library
> to have its own branch for development. Then, when it is deemed
> ready, that branch is promoted to an integration branch. If it
> fails there, the promotion is rolled back until the library is
> changed, gets required changes in another library, etc.
> Eventually, all libraries compile and test fine in the
> integration branch and the whole set can be promoted to a release
> IOW, promotion for integration should be happening throughout the
> year, but only when a given library is ready to do so. A release
> is nothing more than taking a timely snapshot of the integration
> branch. That also means that those that don't want bleeding edge
> changes, but want more than was in the last release, can get the
> latest integrated set of libraries from the integration branch.
Yes. The trunk should be ready-to-release at all times, as far as possible. If
you want to make breaking changes, do it on a branch, make it work, and then
integrate to the trunk. Preferably, branches should be as shortlived as
Has anyone got the resources to run a continuous integration build machine? Is
this what the kind people who supply the resources for the release regression
tests do already?
-- Anthony Williams Software Developer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk