From: Doug Gregor (dgregor_at_[hidden])
Date: 2005-02-03 13:18:05
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
>> his errors in the sea of red will not be easy.
> Ok we both made changes that inevitably broke something. Why don't you
> on this other way around?
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
> and do not want to wait for weeks after announcement making sure
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk