From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-02-03 09:38:29
On Thu, 3 Feb 2005 14:57:10 +0100
"Hartmut Kaiser" <hartmutkaiser_at_[hidden]> wrote:
> 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!
While I agree that an announcement should have been made, the tools have
been deprecated for a very long time, and the documentation has also
been around saying that they are deprecated for a very long time as
well. So, I think your anger is a bit misdirected.
What this actually does, is bring up a point about deprecating
interfaces. We like to be "nice" and leave a deprecated interface
around for a while to give users time to move. However, if the
deprecation time is too long, people never move off, because they
forget, or the notice is so old that new users never see it (though the
test-tools reference has said these interfaces are deprecated for a
So, for deprecated interfaces, it makes sense to make the proper
announcement in the docs, and then when the author decides to act on the
statement "Old deprecated names are still accepted but may be excluded
in a future releases." another announcement should be made, saying that
the removal is being planned, so everyone has time to properly move.
> All in all this incident forces me to think about moving away from
> using Boost.Test in my own code in the future.
This seems a bit rash, since most libraries that have been around for a
while have deprecated interfaces, and eventually, they will be removed
as well. Maybe we should have authors place a message to this list any
time stuff is being deprecated, so that it is easily searchable... or
maybe there should be a common place in the boost documents that any
deprecation announcements can stay so that it is easy to know what is
planned for removal, or has been removed.
Also, for core stuff, it proabably makes sense to make the change in a
branch, announce the change, branch, and proposed date of merge. This
gives developers a chance to make changes as they can relative to that
branch, before the final commit.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk