From: Hartmut Kaiser (hartmutkaiser_at_[hidden])
Date: 2005-02-03 08:57:10
> >>> 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.
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk