varl/qmk_firmware
1
0
Fork 0
forked from forks/qmk_firmware
Code Pull requests Activity
qmk_firmware/docs/breaking_changes.md
James Young 624359b725
2021 February 27 Breaking Changes Changelog (#11975) 
* restore main readme.md

* add ChangeLog entry for 2021-02-27 develop branch - initial version

* update Docs; consolidate sidebar entries to new Breaking Changes History doc

* Changelog update

- concatenate similar changes as one list item
- unify change formatting (remove [bracketed] headings and trailing periods)
- item sorting improvement

* update Changes Requiring User Action section

Detail the changes regarding keyboard relocations/additions/deletions.

* add entry for fauxpark's user keymap cleanup for config.h/rules.mk

* add link to Jacky Studio bugfix PR

* add link for "ChibiOS conf migrations... take 15"

* add links for "Make LAYOUT parsing more robust" and "Massdrop develop rgb fix"

* remove sort sequence numbers

* rename Breaking Changes History page

Renames the Breaking Changes History page to "Past Breaking Changes".

* update schedule in Breaking Changes Overview

* suggestions/changes per tzarc

* skully's changes

* add entry for "Fix develop" (PR 12039)

Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Zach White <skullydazed@gmail.com>
2021-02-27 12:10:23 -08:00

3.7 KiB
Raw Blame History

Breaking Changes

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?

When is the next Breaking Change?

The next Breaking Change is scheduled for February 27, 2021.

Important Dates

  • 2021 Feb 27 - develop is created. Each push to master is subsequently merged to develop
  • 2021 May 01 - develop closed to new PR's.
  • 2021 May 01 - Call for testers.
  • 2021 May 27 - master is locked, no PR's merged.
  • 2021 May 29 - Merge develop to master.
  • 2021 May 29 - master is unlocked. PR's can be merged again.

What changes will be included?

To see a list of breaking change candidates you can look at the breaking_change label. 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
    • git push origin develop
    • git push --tags

4 Weeks Before Merge

  • develop is now closed to new PR's, only fixes for current PR's may be merged
  • Post call for testers

1 Week Before Merge

2 Days Before Merge

Day Of Merge

  • qmk_firmware git commands
    • git checkout develop
    • git pull --ff-only
    • git rebase origin/master
    • Edit readme.md
      • Remove the notes about develop
    • Roll up the ChangeLog into one file.
    • git commit -m 'Merge point for <DATE> Breaking Change'
    • git push origin develop
  • GitHub Actions
    • Create a PR for develop
    • Make sure travis comes back clean
    • Merge develop PR