On Feb 3, 2005, at 12:47 PM, Gennadiy Rozental wrote:
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.
Ok we both made changes that inevitably broke something. Why don't you look on this other way around?
Several reasons: 1) We had warning about the type_traits changes. 2) Few things actually broke, and AFAICT only on broken compilers. 3) The test lib change could be viewed as gratuitous, because the cost of not making the change is negligible (i.e., the macros could have stayed and nobody would have been hurt).
That's why I am have very limitted amount of time when I could make changes and do not want to wait for weeks after announcement making sure everybody had time/ heard about it.
Understood. Would waiting to remove 3 deprecated macros really have slowed you down any?
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.
Ok. I am ready to make this a policy: One week notice for removed depricated interfaces.
Thank you. If nobody is using the interfaces, pull 'em out for sure. What happened here was that the interface was heavily used by Boost, so the impact of pulling them out was huge, and we needed time to deal with that. Doug