Backward compatibility pain

The post argues that backward compatibility creates hard tradeoffs in APIs. It uses three .NET 4.6 examples to show how a fix or improvement can leave existing code broken, even when the change makes the system more correct or more flexible.

Reading notes

#

• OrderByDescending fails with valid comparers when IComparer.Compare returns int.MinValue, because the implementation reverses order with unary negation.
• A safer fix would be to use Math.Sign or reverse the comparer arguments, but the post criticizes keeping the bug to avoid breaking incorrect comparer implementations.
• TimeZoneInfo in .NET 4.6 can now represent changing standard offsets over history, which improves the model.
• That same change makes it harder to predict GetUtcOffset from AdjustmentRule alone, because the rule does not expose the new offset information directly.
• PersianCalendar changes in .NET 4.6 to use a more complex leap-year formula aligned with Windows 10.
• The documented simple leap-year rule still matches the new one for a long range around the modern era, so the visible impact is mainly on older dates.
• The author says Noda Time 2.0 will support simple, astronomical, and arithmetic Persian calendars.
• The conclusion says backward compatibility is hard, and the best choice depends on whether the cost of preserving old behavior is worse than the disruption of change.