"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:

At Saturday 2005-04-02 11:10, you wrote:

...

...

I'll agree again. The changes I check in when we are in release mode (have a release branch active) _always_ go to both the trunk and the branch. The branch doesn't help me in any way.

Apr 15: feature freeze Release "when it's done"

If "when it's done" is short enough, e.g. 2-3 weeks, then it's not even worth branching. Better to just concentrate on getting kinks out for the release. Is this at all realistic?

the reason for the branch is to that those developers who need to work on stuff NOT related to the release have someplace to put their "commits".

In that case you and Doug have different things in mind. I predict this whole thing is going to cause lots of confusion and chaos unless people get it very clear (quickly) what's happening and make sure it's well advertised. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Victor A. Wagner Jr. <vawjr <at> rudbek.com> writes:

At Saturday 2005-04-02 16:57, you wrote:

...

"Victor A. Wagner Jr." <vawjr <at> rudbek.com> writes:

...

the reason for the branch is to that those developers who need to work on stuff NOT related to the release have someplace to put their "commits".

In that case you and Doug have different things in mind.

I didn't see anything that Doug said that disagrees. he hasn't said anything about people working on stuff other than the release

Doug said that the branch could happen at the point of release, and it would contain the release. You are suggesting that the branch happen before release, and that the release would not be on a branch. The only way to resolve these two ideas is to branch twice, and I haven't heard anyone suggest that one yet. -Dave

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