This document describes QMK's Breaking Change process. A Breaking Change is any change which modifies how QMK behaves in a way that in incompatible or potentially dangerous. We limit these changes so that users can have confidence that updating their QMK tree will not break their keymaps.
The breaking change period is when we will merge PR's that change QMK in dangerous or unexpected ways. There is a built-in period of testing so we are confident that any problems caused are rare or unable to be predicted.
## What has been included in past Breaking Changes?
To see a list of breaking change candidates you can look at the [`breaking_change` label](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Abreaking_change+is%3Apr). New changes might be added between now and when `develop` is closed, and a PR with that label applied is not guaranteed to be merged.
If you want your breaking change to be included in this round you need to create a PR with the `breaking_change` label and have it accepted before `develop` closes. After `develop` closes no new breaking changes will be accepted.
Criteria for acceptance:
* PR is complete and ready to merge
* PR has a ChangeLog
# Checklists
This section documents various processes we use when running the Breaking Changes process.
## Creating the `develop` branch
This happens immediately after the previous `develop` branch is merged.
*`qmk_firmware` git commands
* [ ]`git checkout master`
* [ ]`git pull --ff-only`
* [ ]`git checkout -b develop`
* [ ] Edit `readme.md`
* [ ] Add a big notice at the top that this is a testing branch.
* [ ] Include a link to this document
* [ ]`git commit -m 'Branch point for <DATE> Breaking Change'`
* [ ]`git tag breakpoint_<YYYY>_<MM>_<DD>`
* [ ]`git tag <next_version>` # Prevent the breakpoint tag from confusing version incrementing