On 10/4/2011 1:29 PM, Gennadiy Rozental wrote:
Eric Niebler <eric <at> boostpro.com> writes:
On 10/4/2011 10:04 AM, Dave Abrahams wrote:
on Mon Oct 03 2011, Gennadiy Rozental <rogeeff-AT-gmail.com> wrote:
I thought release is based on release branch.
It is. But as you've seen over the years, it causes an unworkable amount of upset and alarm when large numbers of failures appear on the trunk all at once, and people who would otherwise be dealing with release issues now have trunk issues to worry about.
It also interferes with those of us who use trunk health to know when it's safe to merge fixes to the release branch. We're basically flying blind right now.
Do you have any particular library in mind?
All of them? I use trunk health to determine when to merge to release for all of my libraries. And that's the current suggested development model for all Boost libraries, AFAIK.
I'd like to second the call to revert these changes.
And while we at it, let's revert all the changes to Boost.Build, so I can run my own regression test against trunk version of it.
I wasn't aware there was a problem with Boost.Build on trunk. What are you referring to? Link pls.
I already reverted test_exec_monitor for now. I can reinstate other deprecated interfaces, but let's see if there is actually a problem (aside boost.math).
I think there is. All of my tests that use Boost.Test are crashing at runtime with any version of gcc. I don't use any deprecated Boost.Test interfaces, AFAIK. And my tests also fail to compile with msvc 9 and 8 due to this: ..\..\..\boost/test/utils/lazy_ostream.hpp(61) : warning C4181: qualifier applied to reference type; ignored c:\boost\org\trunk\libs\xpressive\test\./test.hpp(104) : see reference to class template instantiation 'boost::unit_test::lazy_ostream_impl<Pr evType,T,StorageT>' being compiled with [ PrevType=const boost::unit_test::lazy_ostream &, T=std::string, StorageT=const std::string & ] Gennadiy, you've heard enough people complain now. I implore you: please revert all your changes, and seriously consider testing them exhaustively on a branch against *all* of Boost before re-committing them. And on more compilers than just msvc-10. -- Eric Niebler BoostPro Computing http://www.boostpro.com