Member-only story
How To Deprecate APIs the Right Way
Deprecate your old APIs with the consciousness of your users
The only certainty in software development is that requirements change.
How many times has this happened to you? You start a project, develop an app to satisfy the requirements, release it, and everyone is happy. The product manager comes back and asks to add a new feature. Suddenly, you have to pass an extra parameter or change the name of a property. You make the change, and other parts of the app start erroring, even parts handled by other teams.
Whether you are working on a library, a framework, or even just a module of an app, you need to be considerate of all of its possible consumers. If you introduce a breaking change, you must give your users the time and tools to adjust their code.
Today, I want to explore what is a breaking change, what kind of changes can be considered breaking, and what techniques can be used to propagate those changes safely.
What Is a Breaking Change?
A breaking change is a change in the code that requires other parts of the code to change to keep the system working.
The simplest example is when you change the name of a property in a public API: every other component that uses that…
