mirror of
https://github.com/firewalkwithm3/qmk_firmware.git
synced 2024-11-22 11:30:30 +08:00
Update branch names to reflect configurator's new deployment. (#19999)
This commit is contained in:
parent
6fabc330e3
commit
7ebb8c2dec
|
@ -34,7 +34,7 @@ The next Breaking Change is scheduled for May 28, 2023.
|
||||||
|
|
||||||
## What changes will be included?
|
## What changes will be included?
|
||||||
|
|
||||||
To see a list of breaking changes merge candidates you can look at the [`core` label](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Acore+is%3Apr). This label is applied whenever a PR is raised or changed, but only if the PR includes changes to core areas of QMK Firmware. A PR with that label applied is not guaranteed to be merged in the current cycle. New changes might be added between now and when `develop` is closed, and it is generally the responsibility of the submitter to handle conflicts. There is also another label used by QMK Collaborators -- `breaking_change_YYYYqN` -- which signifies to maintainers that it is a strong candidate for inclusion, and should be prioritised for review.
|
To see a list of breaking changes merge candidates you can look at the [`core` label](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Acore+is%3Apr). This label is applied whenever a PR is raised or changed, but only if the PR includes changes to core areas of QMK Firmware. A PR with that label applied is not guaranteed to be merged in the current cycle. New changes might be added between now and when `develop` is closed, and it is generally the responsibility of the submitter to handle conflicts. There is also another label used by QMK Collaborators -- `breaking_change_YYYYqN` -- which signifies to maintainers that it is a strong candidate for inclusion, and should be prioritized for review.
|
||||||
|
|
||||||
If you want your breaking change to be included in this round you need to create a PR and have it accepted by QMK Collaborators before `develop` closes. After `develop` closes, new submissions will be deferred to the next breaking changes cycle.
|
If you want your breaking change to be included in this round you need to create a PR and have it accepted by QMK Collaborators before `develop` closes. After `develop` closes, new submissions will be deferred to the next breaking changes cycle.
|
||||||
|
|
||||||
|
@ -127,12 +127,12 @@ This happens immediately after the previous `develop` branch is merged to `maste
|
||||||
* Validate each submodule SHA1 matches the qmk fork, e.g. for ChibiOS:
|
* Validate each submodule SHA1 matches the qmk fork, e.g. for ChibiOS:
|
||||||
* Go to [qmk/ChibiOS](https://github.com/qmk/ChibiOS)
|
* Go to [qmk/ChibiOS](https://github.com/qmk/ChibiOS)
|
||||||
* Compare the commit hash in the above output to the commit hash in the repository
|
* Compare the commit hash in the above output to the commit hash in the repository
|
||||||
* If there's a mismatch, that repository needs to have its `master` branch updated to match (otherwise Configurator won't work):
|
* If there's a mismatch, that repository needs to have its `qmk-master` branch updated to match (otherwise Configurator won't work):
|
||||||
* `cd lib/chibios`
|
* `cd lib/chibios`
|
||||||
* `git fetch --all`
|
* `git fetch --all`
|
||||||
* `git checkout master`
|
* `git checkout qmk-master`
|
||||||
* `git reset --hard <commit hash>`
|
* `git reset --hard <commit hash>`
|
||||||
* `git push origin master --force-with-lease`
|
* `git push origin qmk-master --force-with-lease`
|
||||||
|
|
||||||
* Announce that both `master` and `develop` are now unlocked -- message `@Breaking Changes Updates` on `#qmk_firmware` in Discord:
|
* Announce that both `master` and `develop` are now unlocked -- message `@Breaking Changes Updates` on `#qmk_firmware` in Discord:
|
||||||
* `@Breaking Changes Updates -- Hey folks, develop has now been merged into master -- newest batch of changes are now available for everyone to use!`
|
* `@Breaking Changes Updates -- Hey folks, develop has now been merged into master -- newest batch of changes are now available for everyone to use!`
|
||||||
|
|
|
@ -4,7 +4,7 @@ ChibiOS and ChibiOS-Contrib need to be updated in tandem -- the latter has a bra
|
||||||
|
|
||||||
## Getting ChibiOS
|
## Getting ChibiOS
|
||||||
|
|
||||||
* `svn` Initialisation:
|
* `svn` Initialization:
|
||||||
* Only needed to be done once
|
* Only needed to be done once
|
||||||
* You might need to separately install `git-svn` package in your OS's package manager
|
* You might need to separately install `git-svn` package in your OS's package manager
|
||||||
* `git svn init --stdlayout --prefix='svn/' http://svn.osdn.net/svnroot/chibios/`
|
* `git svn init --stdlayout --prefix='svn/' http://svn.osdn.net/svnroot/chibios/`
|
||||||
|
@ -21,7 +21,7 @@ ChibiOS and ChibiOS-Contrib need to be updated in tandem -- the latter has a bra
|
||||||
|
|
||||||
## Getting ChibiOS-Contrib
|
## Getting ChibiOS-Contrib
|
||||||
|
|
||||||
* `git` Initialisation:
|
* `git` Initialization:
|
||||||
* `git clone git@github.com:qmk/ChibiOS-Contrib`
|
* `git clone git@github.com:qmk/ChibiOS-Contrib`
|
||||||
* `git remote add upstream https://github.com/ChibiOS/ChibiOS-Contrib`
|
* `git remote add upstream https://github.com/ChibiOS/ChibiOS-Contrib`
|
||||||
* `git checkout -b chibios-20.3.x upstream/chibios-20.3.x`
|
* `git checkout -b chibios-20.3.x upstream/chibios-20.3.x`
|
||||||
|
@ -57,3 +57,16 @@ ChibiOS and ChibiOS-Contrib need to be updated in tandem -- the latter has a bra
|
||||||
* `git commit -am 'Update ChibiOS to 99.9.9'`
|
* `git commit -am 'Update ChibiOS to 99.9.9'`
|
||||||
* `git push --set-upstream origin chibios-version-bump`
|
* `git push --set-upstream origin chibios-version-bump`
|
||||||
* Make a PR to qmk_firmware with the new branch
|
* Make a PR to qmk_firmware with the new branch
|
||||||
|
|
||||||
|
## When merging a PR containing an upgrade of ChibiOS/ChibiOS-Contrib:
|
||||||
|
|
||||||
|
* Update the target branch if the merge target was `master`:
|
||||||
|
* `git checkout qmk-master`
|
||||||
|
* `git reset --hard develop_YYYY_qN`
|
||||||
|
* `git push origin qmk-master --force-with-lease`
|
||||||
|
* Update the target branch if the merge target was `develop`:
|
||||||
|
* `git checkout qmk-develop`
|
||||||
|
* `git reset --hard develop_YYYY_qN`
|
||||||
|
* `git push origin qmk-develop --force-with-lease`
|
||||||
|
|
||||||
|
Note that when merging `develop` to `master`, the first workflow should still be followed.
|
||||||
|
|
Loading…
Reference in a new issue