"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> escribió en el mensaje news:cbqrun$e6f$1@sea.gmane.org...
I think Dave's point was that Boost.Test is special: It has to freeze earlier because the regression tests rely on it.
Darren
Boost.Test rely on some other boost components (mpl for example). Does that mean all of them need to be freezed? And how earlier?
Wow... really? what part of MPL exactly?
Almost of the MPL will continue to work as before, and will be well-tested on a variety of platforms. The chance of that dependency disrupting something is very low... and historically, MPL changes have almost never caused regressions. Furthermore, as many libraries depend on MPL directly as depend on Boost.Test, so I don't worry about Boost.Test's dependency on MPL. <opinion>
Boost.Test is unboutless special and must be freezed at least 1 month before release. </opinion>
["unboutless" isn't familiar to me]
If Boost.Test relies on something else (which should be the less possible), these should be frozen too.
Please, make a detailed list of all the library *features* you depend on and plan to freeze Boost.Test really soon (much much sooner than branch date).
Based on past experience, the chance that a late change to Boost.Test will disrupt the release process is rather high, so I also request that you make every effort to freeze as soon as possible. If new features are not required in order to get this release out, maybe they should be left on a branch for a month. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com