It's been deprecated *since the dawn of time*. I planned post an announcement together with library update announcement.
Still, developers like to avoid broken regression tests; they're upsetting to developers at best. A simple post with advance warning that you were going to remove BOOST_TEST would have given everyone an opportunity to prevent a large swath of red squares.
What's wrong with red squares? Isn't it a basic paradigm of TDD? You make change - you fix all the test cases that failed. Failing test cases is your announcement that something needs to be done.
The problem is that a red square due to this change (that could have been avoided if you had given us warning) will mask other problems, so it slows development. For instance, John put in some type_traits changes that inevitably broke something, somewhere, but for him to find his errors in the sea of red will not be easy.
Anyway 3 years should've been enough to get rid of tools that were announced deprecated.
Sure. The problem is that the Test lib is one of those core libraries, like type_traits, where changes ripple through and can cause a lot of problems. We just need to know when deprecated bits are being removed, because it's very likely that some of us didn't even know they were deprecated until they were gone.
Agreed 100%. Let me say, that I'm quite upset about the rude way, how Gennadij decided to force a whole bunch of Boost developers (including me) to invest their time _now_, even if they had not planned to spent their time on this at this moment. I for my part didn't even know, that BOOST_TEST was depreciated (where is this documented?). Changing such a central part without further notice isn't the right way to go! We're all volunteering in Boost and it's unecessary to put additional burden onto everybody here, simply ignoring possible time constraints other people may have. Nevertheless I have some questions regarding this change: - Is there any documented migration path from BOOST_TEST? Perhaps a standard way to do it? - Is there a version number associated with the test library, which I can use to handle this change correctly in my code, even in between different Boost versions (we'll need some time until V1.33 get's out of the door, I assume)? I still have to support older versions of Boost for some time. All in all this incident forces me to think about moving away from using Boost.Test in my own code in the future. Regards Hartmut