mg/qmk_sweep_skeletyl
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
qmk_sweep_skeletyl/docs/breaking_changes_instructions.md
James Young fced377ac0
2020 May 30 Breaking Changes Update (#9215) 
* Branch point for 2020 May 30 Breaking Change

* Migrate `ACTION_LAYER_TOGGLE` to `TG()` (#8954)

* Migrate `ACTION_MODS_ONESHOT` to `OSM()` (#8957)

* Migrate `ACTION_DEFAULT_LAYER_SET` to `DF()` (#8958)

* Migrate `ACTION_LAYER_MODS` to `LM()` (#8959)

* Migrate `ACTION_MODS_TAP_KEY` to `MT()` (#8968)

* Convert V-USB usbdrv to a submodule (#8321)

* Unify Tap Hold functions and documentation (#8348)

* Changing board names to prevent confusion (#8412)

* Move the Keyboardio Model01 to a keyboardio/ subdir (#8499)

* Move spaceman keyboards (#8830)

* Migrate miscellaneous `fn_actions` entries (#8977)

* Migrate `ACTION_MODS_KEY` to chained mod keycodes (#8979)

* Organizing my keyboards (plaid, tartan, ergoinu) (#8537)

* Refactor Lily58 to use split_common (#6260)

* Refactor zinc to use split_common (#7114)

* Add a message if bin/qmk doesn't work (#9000)

* Fix conflicting types for 'tfp_printf' (#8269)

* Fixed RGB_DISABLE_AFTER_TIMEOUT to be seconds based & small internals cleanup (#6480)

* Refactor and updates to TKC1800 code (#8472)

* Switch to qmk forks for everything (#9019)

* audio refactor: replace deprecated PLAY_NOTE_ARRAY (#8484)

* Audio enable corrections (2/3) (#8903)

* Split HHKB to ANSI and JP layouts and Add VIA support for each (#8582)

* Audio enable corrections (Part 4) (#8974)

* Fix typo from PR7114 (#9171)

* Augment future branch Changelogs (#8978)

* Revert "Branch point for 2020 May 30 Breaking Change"
2020-05-30 13:14:59 -07:00

3.5 KiB
Raw Blame History

Breaking Changes: My Pull Request Was Flagged

A QMK member may have replied to your pull request stating that your submission is a breaking change. In their judgment, the changes you have proposed have greater implications for either QMK, or its users.

Some things that may cause a pull request to be flagged are:

  • Edits to User Keymaps A user may submit their keymap to QMK, then some time later open a pull request with further updates, only to find it can't be merged because it was edited in the qmk/qmk_firmware repository. As not all users are proficient at using Git or GitHub, the user may find themself unable to fix the issue on their own.
  • Changes to Expected Behavior Changes to QMK behavior may cause users to believe their hardware or QMK is broken if they flash new firmware that incorporates changes to existing QMK features, and find themselves without a means to restore the desired behavior.
  • Changes Requiring User Action Changes may also require action to be taken by users, such as updating a toolchain or taking some action in Git.
  • Changes Necessitating Increased Scrutiny On occasion, a submission may have implications for QMK as a project. This could be copyright/licensing issues, coding conventions, large feature overhauls, "high-risk" changes that need wider testing by our community, or something else entirely.
  • Changes Requiring Communication to End Users This includes warnings about future deprecations, outdated practices, and anything else that needs to be communicated but doesn't fit into one of the above categories.

What Do I Do?

If it is determined that your submission is a breaking change, there are a few things you can do to smooth the process:

Consider Splitting Up Your PR

If you are contributing core code, and the only reason it needs to go through breaking changes is that you are updating keymaps to match your change, consider whether you can submit your feature in a way that the old keymaps continue to work. Then submit a separate PR that goes through the breaking changes process to remove the old code.

Contribute a ChangeLog Entry

We require submissions that go through the Breaking Change process to include a changelog entry. The entry should be a short summary of the changes your pull request makes – each section here started as a changelog.

Your changelog should be located at docs/ChangeLog/YYYYMMDD/PR####.md, where YYYYMMDD is the date on which QMK's breaking change branch – usually named develop – will be merged into the master branch, and #### is the number of your pull request.

If your submission requires action on the part of users, your changelog should instruct users what action(s) must be taken, or link to a location that does so.

Document Your Changes

Understanding the purpose for your submission, and possible implications or actions it will require can make the review process more straightforward. A changelog may suffice for this purpose, but more extensive changes may require a level of detail that is ill-suited for a changelog.

Commenting on your pull request and being responsive to questions, comments, and change requests is much appreciated.

Ask for Help

Having your submission flagged may have caught you off guard. If you find yourself intimidated or overwhelmed, let us know. Comment on your pull request, or reach out to the QMK team on Discord.