Eric Niebler wrote:
This would eliminate the requirement for any kind of "freeze"
Let me understand ... it would eliminate the need for a tool freeze *on trunk*, not on release. A freeze on the release branch is essential and standard practice. And IMO the freeze on tools should happen earlier ... by some weeks as Volodya suggested ... than the freeze on libraries.
OK - I guess we're sort of splitting hairs here. as a practical matter, I would be reluctant to merge any changes into the release near to the release target date. It would be on a case by case basis. Actually, its interesting I find myself in exactly this situation right this minute. We have a bug in the serialization library. It only shows up in certain circumstances on certain versions of the gcc compiler and on none of the test platforms. (I don't think anyone will argue that the serialization library doesn't have enough tests). It's ever worse, if one has this bug, there is no way to work around it. Now, after months of trying to track this down, Troy d. straszheim has managed to make a repeatable test that fails in his environment and I think I've finally managed to fix it. It looks like the latest fix hasn't broken anything else and hopefully Troy will be able to verify that his test case now passes. This illustrates the following for the new procedure. a) In spite of one's best efforts, s*** happens. b) This situation isn't holding up the whole release for everyone else c) Even if we don't get the bug fix into this release, the serialization and boost 1.37 as a whole will be strictly better than the previous version. d) These improvements will be be available to users in a timely manner. So, I believe our experience with the current release process demontrates a huge improvement over the previous one. Robert Ramey