On Sat, 02 Apr 2005 21:30:10 -0700, Victor A. Wagner Jr. wrote
I'm suggesting that we tag (with a branchable tag) the freeze point. If you're going to work on stuff not going in 1.33 commit your changes on a branch that you make from there. After the release, merge all your stuff back onto the main branch. This way, all the developers (and testers) working on the release continue as normal.
I think I'm with Peter and Victor on this. I too, end up merging all my branch changes immediately to the main branch -- so the current process is leading to more work during post-branch release phases. However, as I recall, this process came about because of a 2 factors: 1) lack of discipline by developers and 2) the length of time required to complete the release. The past couple releases have proven that branching didn't improve discipline. So the message needs to be clear to developers -- don't try to rush last minute stuff into the release -- do changes on a branch and wait until the release is done. For this release I don't believe we have any 'must-have' features that will perturb the schedule. For example, if ptr_container, wave, or hash don't stabalize by the freeze date we should remove them from the release instead of holding the release schedule. New libraries are easy to remove since they don't have any dependent libs yet (yes I know about the hash --> multiindex relationship). Also, I'll say it again, we need to stabalize and freeze and fix the 'core libraries' (type traits, test) immediately so that we can sort the real failures from the induced failures. When Boost.test is yellow or red on every compiler (as is currently the case) it makes it difficult to tell if the other libs are really broken or it's just a Boost.Test problem. In addition, changes in these core libs will slow regression tests because virtually everything has to recompile when there are check-ins in these libs. Jeff