
On Thu, 3 Feb 2005 14:57:10 +0100 "Hartmut Kaiser" <hartmutkaiser@t-online.de> 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 while). 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.