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 property has to update the name to the new one.