Repository navigation
feat: Track ZMK main (Zephyr 4.1) for the upcoming 0.4.0 line - #9
Conversation
Mirror the guidance added to the v0.3.0 branch onto main: explain that the oskey revision must match the zmk revision (oskey compiles against ZMK internal APIs that change between versions), with a mapping table in the README Installation section and a "Versioning & branches" section in AGENTS.md. On this branch the reference revision is `main` (ZMK main / Zephyr 4.1 / the upcoming 0.4.0). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jamescrosswell
left a comment
There was a problem hiding this comment.
Thank you for the PR @andrewxhc - much appreciated!
To make this work, I've changed the branching strategy for OSKey to match what's used in ZMK... so I've created a v0.3.0 branch from what was previously the head on main (along with a bit of a blurb in the readme explaining this).
That means we can now accept this commit to OSKey's main branch (which will now become OSKey's 'unstable' branch and can be used for any other changes required to maintain compatibility with the next/latest version of ZMK).
| - name: zmk | ||
| url: https://github.com/zmkfirmware/zmk | ||
| revision: v0.3.0 | ||
| revision: 0331b7d16e80954b807917f9323e59ffc1e3b626 |
There was a problem hiding this comment.
I guess since ZMK v0.4.0 hasn't yet been released, a commit hash is the only 'stable' label we can use for testing purposes. Just need to remember to bump this periodically to make sure OSKey still works with the latest code in the ZMK repo. I think that's a better option than trying to reference main (and having non-deterministic tests).
|
Awesome, this new branching strategy makes sense to me. Thanks for all your work on this repo, it’s been a big lifesaver for me! |
Updates oskey for newer ZMK / Zephyr 4.1-era builds.
Changes:
os-layer-modlayer activation/deactivation calls for the newer ZMK keymap API.native_posix_64.keymaptonative_sim.keymap.v0.3.0to a ZMK 4.1-era commit.zmk-build-arm:3.5tozmk-build-arm:4.1.This is an alternative to the docs-only compatibility note in #8 ; if this PR is accepted, that docs-only change can be closed or superseded.