Breaking changes for 2022q2. (#17221)

docs/ChangeLog/20220528.md

@@ -2,14 +2,72 @@
 
 ## Notable Features :id=notable-features
 
-### TODO
+### Caps Word ([#16588](https://github.com/qmk/qmk_firmware/pull/16588)) :id=caps-word
+
+This is a new feature that allows for capslock-like functionality that turns itself off at the end of the word.
+
+For instance, if you wish to type "QMK" without holding shift the entire time, you can either tap both left and right shift, or double-tap shift, to turn on _Caps Word_ -- then type `qmk` (lowercase) without holding shift. Once you hit any key other than `a`--`z`, `0`--`9`, `-`, `_`, delete, or backspace, this will go back to normal typing!
+
+There are other activation mechanisms as well as configurable options like timeout and the like -- see the [Caps Word documentation](feature_caps_word.md) for more information.
+
+### Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174)) :id=quantum-painter
+
+QMK has had support for small OLED displays for some time now, but hasn't really gained too much ability to draw to panels other than the SSD1306 or SH1106 panels.
+
+Quantum Painter is a new drawing subsystem available to suitable ARM and RISC-V boards that is capable of drawing to large panel RGB LCDs and RGB OLEDs. It also allows for a lot more flexibility with a larger set of drawing APIs -- lines, rectangles, circles, ellipses, text, images, and even animations.
+
+The QMK CLI has new commands added to be able to generate images and fonts for Quantum Painter to digest -- it's even capable of converting animated gifs for display on screen.
+
+See the [Quantum Painter documentation](quantum_painter.md) for more information on how to set up the displays as well as how to convert images and fonts.
+
+!> Quantum Painter is not supported on AVR due to complexity and size constraints. Boards based on AVR such as ProMicro or Elite-C builds will not be able to leverage Quantum Painter.
+
+### Encoder Mapping ([#13286](https://github.com/qmk/qmk_firmware/pull/13286)) :id=encoder-mapping
+
+One of the long-standing complaints with Encoders is that there has been no easy way to configure them in user keymaps. [#13286](https://github.com/qmk/qmk_firmware/pull/13286) added support for [Encoder Mapping](feature_encoders.md#encoder-map), which allows users to define encoder functionality in a similar way to their normal keymap.
+
+!> This is not yet supported by QMK Configurator. It is also unlikely to ever be supported by VIA.
+
+## Changes Requiring User Action :id=changes-requiring-user-action
+
+### `RESET` => `QK_BOOT` ([#17037](https://github.com/qmk/qmk_firmware/pull/17037)) :id=reset-2-qk_boot
+
+QMK is always in the process of picking up support for new hardware platforms. One of the side-effects for future integrations has shown that QMK's usage of `RESET` as a keycode is causing naming collisions. As a result, [#17037](https://github.com/qmk/qmk_firmware/pull/17037) changed usages of `RESET` to the new keycode `QK_BOOT` in the majority of default-like keymaps. At this stage the old keycode is still usable but will likely be removed in the next breaking changes cycle. Users with keymaps containing `RESET` should also move to `QK_BOOT`.
+
+### Sendstring keycode overhaul ([#16941](https://github.com/qmk/qmk_firmware/pull/16941)) :id=sendstring-keycodes
+
+Some keycodes used with `SEND_STRING` and its relatives have been deprecated and may have their old keycode usages removed at a later date. The list of [deprecated keycodes](https://github.com/qmk/qmk_firmware/blob/ebd402788346aa6e88bde1486b2a835684d40d39/quantum/send_string_keycodes.h#L456-L505) should be consulted to determine if you're using one of the older names (the first identifier after `#define`) -- you should swap to the newer variant (the second identifier on the same line).
+
+### Pillow Installation ([#17133](https://github.com/qmk/qmk_firmware/pull/17133)) :id=pillow-install
+
+The merge of Quantum Painter added some new dependencies in the QMK CLI, most notably _Pillow_, which requires some installation in order for the CLI to function. If you've got an existing installation, you'll need to run some commands in order to get things working:
+
+On Windows, if using _QMK MSYS_ or _msys2_, you'll need to run the following command:
+
+```sh
+pacman --needed --noconfirm --disable-download-timeout -S mingw-w64-x86_64-python-pillow
+python3 -m pip install --upgrade qmk
+```
+
+On macOS:
+
+```sh
+brew update
+brew upgrade qmk/qmk/qmk
+```
+
+On Linux or WSL:
+
+```sh
+python3 -m pip install --user --upgrade qmk
+```
 
 ### Updated Keyboard Codebases :id=updated-keyboard-codebases
 
 The following keyboards have had their source moved within QMK:
 
 | Old Keyboard Name    | New Keyboard Name  |
-|-----------------------|--------------------|
+|----------------------|--------------------|
 | absinthe             | keyhive/absinthe   |
 | amj40                | amjkeyboard/amj40  |
 | amj60                | amjkeyboard/amj60  |
@@ -37,13 +95,9 @@ The following keyboards have had their source moved within QMK:
 | wheatfield/split75   | mt/split75         |
 | z150_bh              | viktus/z150_bh     |
 
-## Notable core changes :id=notable-core
-
-### TODO
-
 ---
 
-## Full changelist
+## Full changelist :id=full-changelist
 
 Core:
 * Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174))
@@ -120,6 +174,7 @@ Keyboards:
 * Helix/rev2 move to split common ([#16723](https://github.com/qmk/qmk_firmware/pull/16723))
 * Remove some layout exceptions ([#16957](https://github.com/qmk/qmk_firmware/pull/16957))
 * Refactor legacy quantum keycodes in default-ish keymaps ([#17037](https://github.com/qmk/qmk_firmware/pull/17037))
+* Refactor legacy quantum keycodes in default-ish keymaps ([#17150](https://github.com/qmk/qmk_firmware/pull/17150))
 
 Keyboard fixes:
 * gboards/gergoplex: move `COMBO_ENABLE` to keymap level ([#16667](https://github.com/qmk/qmk_firmware/pull/16667))

docs/breaking_changes.md

@@ -22,17 +22,17 @@ The breaking change period is when we will merge PR's that change QMK in dangero
 
 ## When is the next Breaking Change?
 
-The next Breaking Change is scheduled for May 28, 2022.
+The next Breaking Change is scheduled for August 27, 2022.
 
 ### Important Dates
 
-* [x] 2022 Feb 26 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
+* [x] 2022 May 28 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
-* [ ] 2022 Apr 31 - `develop` closed to new PR's.
+* [ ] 2022 Jul 31 - `develop` closed to new PR's.
-* [ ] 2022 Apr 31 - Call for testers.
+* [ ] 2022 Jul 31 - Call for testers.
-* [ ] 2022 May 14 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
+* [ ] 2022 Aug 13 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
-* [ ] 2022 May 26 - `master` is locked, no PR's merged.
+* [ ] 2022 Aug 25 - `master` is locked, no PR's merged.
-* [ ] 2022 May 28 - Merge `develop` to `master`.
+* [ ] 2022 Aug 27 - Merge `develop` to `master`.
-* [ ] 2022 May 28 - `master` is unlocked. PR's can be merged again.
+* [ ] 2022 Aug 27 - `master` is unlocked. PR's can be merged again.
 
 ## What changes will be included?
 
@@ -43,7 +43,7 @@ If you want your breaking change to be included in this round you need to create
 Criteria for acceptance:
 
 * The PR is complete and ready to merge
-* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20220226`.
+* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20220827`.
     * This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PR's ID.
     * One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability.
 

docs/feature_encoders.md

@@ -67,7 +67,7 @@ Additionally, if one side does not have an encoder, you can specify `{}` for the
 #define ENCODER_RESOLUTIONS_RIGHT { 4 }
 ```
 
-## Encoder map
+## Encoder map :id=encoder-map
 
 Encoder mapping may be added to your `keymap.c`, which replicates the normal keyswitch layer handling functionality, but with encoders. Add this to your `rules.mk`: