The principles are pretty simple: If the semantics change significantly, then the name should change.
Conversely, if the name doesn't change the semantics shouldn't change. That is, unless the changes fix seriously broken old semantics or extend old semantics in a way that old calls don't change. Or unless the change is listed explicitly in the INCOMPATIBLE section in a way that people understand (which is unlikely given how few people look at the change notes). ON the other side of the fence, good monitoring and exception alerting are always good. Output size is a key parameter to monitor and alert on. Adaptive alerts aren't that hard to build (just alert on the ratio of today / yesterday or today / last week). On 2/21/08 12:41 PM, "Arun C Murthy" <[EMAIL PROTECTED]> wrote: > We do need to be more diligent about listing config changes in > CHANGES.txt for starters, and that point is taken. However, we can't > start pulling out apis without deprecating them first.
