Backwards compatibility and breaking changes
This page explains the principles of backwards compatibility and breaking changes.
A backwards-compatible change is any change that is not a breaking change. So what is a breaking change?
A breaking change is any change that modifies Kedro's public APIs. Examples include making a change to the signature of public functions or removing a module.
Your change is not considered a breaking change, and so is backwards compatible, if a user can upgrade their Kedro version and include your change without anything breaking in their project.
We aim to minimise the number of breaking changes to keep Kedro software stable and reduce the overhead for users as they migrate their projects. However, there are cases where a breaking change brings considerable value or increases the maintainability of the codebase. In these cases, breaking backwards compatibility can make sense.
Before you contribute a breaking change, you should create a GitHub Issue that describes the change and justifies the value gained by breaking backwards compatibility.
All non-breaking changes go into main, from which a minor release can be deployed at any time.
All breaking changes go into develop, from which a major release can be deployed at any time. The develop branch contains all commits from the main branch, but the main branch does not contain all the commits from develop until the next major release.
Got a question about the development process? Ask the community on Slack if you need to!