lunny/qmk_firmware-mirror
1
0
Fork 0
mirror of https://github.com/qmk/qmk_firmware synced 2025-01-03 13:40:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

develop 2023q2 changelog (#21049)

Browse Source 
Co-authored-by: Ryan <fauxpark@gmail.com>
This commit is contained in:
Nick Brassel
2023-05-29 06:02:11 +10:00
committed by GitHub
parent 8c9f54d70b
commit 32d865572c
7 changed files with 565 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

551
docs/ChangeLog/20230528.md Normal file
View File

File diff suppressed because it is too large Load Diff

21
docs/ChangeLog/20230528/PR14996.md
View File

@ -1,21 +0,0 @@
# QMK Breaking Changes - 2023 May 28 Changelog
## Notable Features :id=notable-features
### Consolidate modelm ([#14996](https://github.com/qmk/qmk_firmware/pull/14996)
Several build targets for the IBM Model M were cluttered in different folders.
The maintainers of several Model M replacement controller projects agreed to
consolidate them under one common folder.
List of the consolidations now in keyboards/modelm/:
- ashpil_usbc
- ibm122m
- mschwingen
- teensy2 (renamed from modelm101_teensy2)
- teensypp (renamed from modelm101)
- teensypp_ssk (renamed from modelm_ssk)
- ibm122m
- m122_3270
- yugo_m

3
docs/ChangeLog/20230528/PR20584.md
View File

@ -1,3 +0,0 @@
Two new boolean callback functions, `pre_process_record_kb` and `pre_process_record_user`, are added in this change. They are called at the beginning of `process_record`, right before `process_combo`.
Similar to existing `*_kb` and `*_user` callback functions, returning `false` will halt further processing of key events. The `pre_process_record_user` function will allow user space opportunity to handle or capture an input before it undergoes quantum processing. For example, while action tapping is still resolving the tap or hold output of a mod-tap key, `pre_process_record_user` can capture the next key record of an input event that follows. That key record can be used to influence the [decision of the mod-tap](https://docs.qmk.fm/#/tap_hold) key that is currently undergoing quantum processing.

24
docs/breaking_changes.md
View File

@ -10,27 +10,25 @@ Practically, this means QMK merges the `develop` branch into the `master` branch
## What has been included in past Breaking Changes?
* [2023 May 28](ChangeLog/20230528.md)
* [2023 Feb 26](ChangeLog/20230226.md)
* [2022 Nov 26](ChangeLog/20221126.md)
* [2022 Aug 27](ChangeLog/20220827.md)
* [2022 May 28](ChangeLog/20220528.md)
* [2022 Feb 26](ChangeLog/20220226.md)
* [Older Breaking Changes](breaking_changes_history.md)
## When is the next Breaking Change?
The next Breaking Change is scheduled for May 28, 2023.
The next Breaking Change is scheduled for August 27, 2023.
### Important Dates
* 2023 Feb 26 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
* 2023 Apr 30 - `develop` closed to new PRs.
* 2023 Apr 30 - Call for testers.
* 2023 May 14 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
* 2023 May 21 - `develop` is locked, only critical bugfix PRs merged.
* 2023 May 26 - `master` is locked, no PRs merged.
* 2023 May 28 - Merge `develop` to `master`.
* 2023 May 28 - `master` is unlocked. PRs can be merged again.
* 2023 May 28 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
* 2023 Jul 30 - `develop` closed to new PRs.
* 2023 Jul 30 - Call for testers.
* 2023 Aug 13 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
* 2023 Aug 20 - `develop` is locked, only critical bugfix PRs merged.
* 2023 Aug 25 - `master` is locked, no PRs merged.
* 2023 Aug 27 - Merge `develop` to `master`.
* 2023 Aug 27 - `master` is unlocked. PRs can be merged again.
## What changes will be included?
@ -50,7 +48,7 @@ Criteria for acceptance:
Strongly suggested:
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20221126`.
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20230827`.
* This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PRs ID.
* One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability.

1
docs/breaking_changes_history.md
View File

@ -2,6 +2,7 @@
This page links to all previous changelogs from the QMK Breaking Changes process.
* [2023 May 28](ChangeLog/20230528.md) - version 0.21.0
* [2023 Feb 26](ChangeLog/20230226.md) - version 0.20.0
* [2022 Nov 26](ChangeLog/20221126.md) - version 0.19.0
* [2022 Aug 27](ChangeLog/20220827.md) - version 0.18.0

8
docs/breaking_changes_instructions.md
View File

@ -23,14 +23,6 @@ If it is determined that your submission is a breaking change, there are a few t
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 &ndash; [each section here started as a changelog](ChangeLog/20190830.md "n.b. This should link to the 2019 Aug 30 Breaking Changes doc - @noroadsleft").
Your changelog should be located at `docs/ChangeLog/YYYYMMDD/PR####.md`, where `YYYYMMDD` is the date on which QMK's breaking change branch &ndash; usually named `develop` &ndash; 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.

4
docs/pr_checklist.md
View File

@ -62,7 +62,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
- valid maintainer
- valid USB VID/PID and device version
- displays correctly in Configurator (press Ctrl+Shift+I to preview local file, turn on fast input to verify ordering)
- `layout` definitions should include matrix positions, so that `LAYOUT` macros can be generated at build time
- `layout` definitions must include matrix positions, so that `LAYOUT` macros can be generated at build time
- should use standard definitions if applicable
- use the Community Layout macro names where they apply (preferred above `LAYOUT`/`LAYOUT_all`)
- If the keyboard only has a single electrical/switch layout:
@ -124,7 +124,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
- hardware that's enabled at the keyboard level and requires configuration such as OLED displays or encoders should have basic functionality implemented here
- `<keyboard>.h`
- `#include "quantum.h"` appears at the top
- `LAYOUT` macros should be moved to `info.json`
- `LAYOUT` macros are no longer accepted and should instead be moved to `info.json`
- keymap `config.h`
- no duplication of `rules.mk` or `config.h` from keyboard
- `keymaps/default/keymap.c`