Designing for Evolution — APIs That Age Well
Every mechanism in this series — versions, gates, specs, deprecations — is the cost of changing decisions already shipped. The cheapest breaking change remains the one you never need, and whether you need many or few is substantially determined at design time, by choices that cost nothing when made and compound forever after. This closing post is that discipline: the additive-evolution patterns, the robustness-principle corrections, and the design review that asks about every surface, "how will this change?"
The cheapest breaking change is the one never needed: objects and envelopes over bare scalars, open sets declared with catch-all semantics, expansion parameters over endpoint forks, names reviewed against their futures — plus the corrected robustness principle and an honest beta ladder. Closes the series.