[1.32 release] Boost.Test plan
I plan to add one more big feature and several small one into this release. I should be able to finish all of this within 3 weeks. I mostly worry about some regression on old compilers. I will try to address most of it before committing. Gennadiy.
"Rozental, Gennadiy" <gennadiy.rozental@thomson.com> writes:
I plan to add one more big feature and several small one into this release. I should be able to finish all of this within 3 weeks. I mostly worry about some regression on old compilers. I will try to address most of it before committing.
Noooooooooooooooooooooooo Please, no. The time to be developing new features that might destabilize Boost.Test was 3 weeks ago (or however long it takes to stabilize it). Boost.Test needs to be stable in the weeks leading up to the branch-for-release. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
The time to be developing new features that might destabilize Boost.Test was 3 weeks ago (or however long it takes to stabilize it). Boost.Test needs to be stable in the weeks leading up to the branch-for-release.
Unfortunately I had other commitments that prevented me from finishing it by that time. I have several long promised features I hoped to include into this release. As I sad I will make sure it is as painless as possible. And I am bound to be finished before branch for release. Gennadiy.
Boost.Test needs to be stable in the weeks leading up to the branch-for-release.
Unfortunately I had other commitments that prevented me from finishing it by that time. I have several long promised features I hoped to include into this release. As I sad I will make sure it is as painless as possible. And I am bound to be finished before branch for release.
I think Dave's point was that Boost.Test is special: It has to freeze earlier because the regression tests rely on it. Darren
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
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> escribió en el mensaje news:cbqrun$e6f$1@sea.gmane.org... that
mean all of them need to be freezed? And how earlier?
Wow... really? what part of MPL exactly? Boost.Test is unboutless special and must be freezed at least 1 month before release. 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). Fernando Cacciola SciSoft
"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
On Tue, 29 Jun 2004 10:30:24 -0400, David Abrahams wrote
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.
Perhaps we should tag the repository now so that we can easily revert to a stable state. Then if something goes wrong we can just back out Boost.Test changes and stay on schedule. It's not as complicated as a branch, but it's just as effective. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Tue, 29 Jun 2004 10:30:24 -0400, David Abrahams wrote
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.
Perhaps we should tag the repository now so that we can easily revert to a stable state. Then if something goes wrong we can just back out Boost.Test changes and stay on schedule. It's not as complicated as a branch, but it's just as effective.
Not quite. With the branch, new code doesn't suddenly arrive and mess up test results for several days and cause various people to pull their hair out and scramble around looking for ways to port the test library code to untested platforms. With the tag we'd have to decide whether to revert or not, etc., etc. Either the changes to the library should be made soon, IMO, or left off the main trunk until the release branch is made (and left off the release branch entirely).
Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Tue, 29 Jun 2004 12:04:30 -0400, David Abrahams wrote
Not quite. With the branch, new code doesn't suddenly arrive and mess up test results for several days and cause various people to pull their hair out and scramble around looking for ways to port the test library code to untested platforms.
Agreed, but I'm assuming that step is already being taken...
With the tag we'd have to decide whether to revert or not, etc., etc.
Yes, but it's an easy decision in my mind. If release schedule is put at risk it gets backed out, period. But in my view it would be the release manager's decision.
Either the changes to the library should be made soon, IMO, or left off the main trunk until the release branch is made (and left off the release branch entirely).
Total agreement. My suggestion was a risk management strategy to give us an option to back out more easily if something goes wrong. Just as an aside, I agree with much of what you, Robert, and John were observing about issues in past releases. In my view, most of the churn was a result of last minute changes in existing libraries that have other dependencies. Boost.Test was one, but there have been others (lexical_cast comes to mind a couple releases back). Then there are boost wide changes like the new dynamic library system that upset things in the last release as well. I don't recall a in single release delay resulting from a new library addition. So at some level I feel Robert is being too cautous with serialization -- but I'm ok with waiting. I think John's list of 'core libraries' was sensible. If we freeze changes in those well in advance then things will be much smoother. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
Just as an aside, I agree with much of what you, Robert, and John were observing about issues in past releases. In my view, most of the churn was a result of last minute changes in existing libraries that have other dependencies. Boost.Test was one, but there have been others (lexical_cast comes to mind a couple releases back). Then there are boost wide changes like the new dynamic library system that upset things in the last release as well.
Yup.
I don't recall a in single release delay resulting from a new library addition. So at some level I feel Robert is being too cautous with serialization -- but I'm ok with waiting.
Yup#2
I think John's list of 'core libraries' was sensible.
link? I missed that.
If we freeze changes in those well in advance then things will be much smoother.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Wed, 30 Jun 2004 07:47:49 -0400, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
I think John's list of 'core libraries' was sensible.
link? I missed that.
It was in another thread... http://lists.boost.org/MailArchives/boost/msg66262.php Jeff
Fernando Cacciola wrote:
"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? Boost.Test is unboutless special and must be freezed at least 1 month before release. 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).
I dare say that Boost.Test should avoid dependencies on boost libraries. I would suggest isolating the MPL dependencies even if that means re-implementing the parts that it uses. Boost.Test is special and avoiding cyclic dependency will help us not go insane. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
I dare say that Boost.Test should avoid dependencies on boost libraries. I would suggest isolating the MPL dependencies even if that means re-implementing the parts that it uses. Boost.Test is special and avoiding cyclic dependency will help us not go insane.
Joel de Guzman
At the moment Boost.Test directly depends on: boost/call_traits.hpp boost/config.hpp boost/config/auto_link.hpp boost/cstdlib.hpp boost/current_function.hpp boost/detail/workaround.hpp boost/function/function0.hpp boost/function/function1.hpp boost/limits.hpp boost/mem_fn.hpp boost/mpl/for_each.hpp boost/mpl/identity.hpp boost/preprocessor/arithmetic/add.hpp boost/preprocessor/repetition/repeat.hpp boost/preprocessor/seq/for_each.hpp boost/progress.hpp boost/scoped_ptr.hpp boost/shared_ptr.hpp boost/type.hpp boost/type_traits/add_const.hpp boost/type_traits/add_pointer.hpp boost/utility.hpp boost/utility/addressof.hpp boost/utility/base_from_member.hpp boost/version.hpp Actually MPL and Boost.Function dependency is not critical yet since it does not affect library compilation and used only for extensions. But I definitely is not going to reimplement all above headers. Don't forget that Boost.Test among other things is standalone library and in may have need for use some existent core components. I wanted to propose to introduce macro BOOST_INTERNAL_TEST. If this macro is defined I will try to ifdef out optional dependencies. Boost libraries authors may define this symbol. Though In general I do not see anything wrong with Boost.Test dependencies on other boost components unless it introduce loops: Boost.Test depends on component that uses Boost.Test for unit testing. I believe it resolvable by using different layers of Boost.Test or with macro proposition above. In a near future I plan to use boost::optional, iterator_facade boost::lexical_cast and probably boost::function and boost::bind. And I am sure dependency keep grow. My only limitation is that it should work on all platforms where we perform regression testing. Regards, Gennadiy.
Joel de Guzman writes:
Fernando Cacciola wrote:
"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? Boost.Test is unboutless special and must be freezed at least 1 month before release. 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).
I dare say that Boost.Test should avoid dependencies on boost libraries. I would suggest isolating the MPL dependencies even if that means re-implementing the parts that it uses. Boost.Test is special and avoiding cyclic dependency will help us not go insane.
FWIW, MPL itself doesn't use Boost.Test, so there is no cyclic dependency here. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (3)
-
Aleksey Gurtovoy -
Darren Cook -
David Abrahams -
Fernando Cacciola -
Gennadiy Rozental -
Jeff Garland -
Joel de Guzman -
Rozental, Gennadiy