Rob Stewart <stewart@sig.com> writes:
From: "AlisdairM" <alisdair.meredith@uk.renaultf1.com>
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 branch.
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 possible. 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 -- Anthony Williams Software Developer