Dean Yu wrote:
I have seen software projects that take this approach. Every single one of them runs into the problem where the software gets completely destabilized from a stampeding herd of checkins after a period of not being able to check in. This is exactly the type of problem that continuous integration is supposed to solve in the first place.
I have also witnessed another problem with the "quiet period" approach on another large scale project I work on - everyone usually rushes to check tons of changes in to the trunk before the weekly "lockdown". Creating a release branch mitigates this somewhat - people can still freely check in changes at their own pace, but they just may not make the weekly release.
As far as merging goes - the release branches should not have to be frequently merged back to the trunk, unless running automated tests against the release branch reveals that patches are required to create a stable release. If you're anti-merging, you can choose to simply not make the release, apply the patches directly to the trunk and wait for the next week's release (or try again with a new, later, release branch).
