chore: add esp32h2 to init chip options, bump to 0.1.0 - #15
Merged
Conversation
rmk-template gained esp32h2 and esp32h2_split templates, but 'rmkit init' had no way to pick them. 0.1.0 rather than 0.0.22: the layout subcommands are a new surface, and the 0.0.x series predates the rmk-rs migration.
This was referenced Aug 15, 2026
…oml as-is A `Cargo.toml` or `memory.x` sitting next to keyboard.toml replaces the template's copy verbatim, so a project can add rmk features, pin dependencies, or change the flash layout without touching the template or the cloud build workflow. When the user provides Cargo.toml, rmkit no longer adjusts the rmk feature list — keyboard.toml/feature mismatches are reported by rmk-macro at build time. Claude-Session: https://claude.ai/code/session_01YPLK88rkh5jqoHmRUdAvUN
Both `rmk-config` and `rynk-kle` were git dependencies, which blocks `cargo publish` outright — 0.1.0 could not have shipped as it stood. Both are on crates.io now (rmk-config 0.7.0, rynk-kle 0.2.0), so point at the published versions. Record in the manifest why the rmk-config version is coupled to the keyboard.toml schema: the config structs are `deny_unknown_fields`, so they reject keys added by later versions and the pin has to move with each rmk release. Checking the chip list against rmk-template also turned up three options that cannot work: `nrf52833`, `nrf52811` and `nrf52810` have no template at all, so choosing one fails with "The specified chip/board does not exist in the template repo". Unlike stm32 there is no family fallback, so stop advertising them. Also move off the yanked rust-ini 0.21.2. Signed-off-by: Haobo Gu <haobogu@outlook.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rmkit had no CI beyond cargo-dist's release workflow, and it hardcodes assumptions about rmk that nothing verifies: the keyboard.toml schema it parses, the cargo feature names it writes into generated projects, and the chips it offers. Those rot silently whenever rmk moves — 89c4796 was cleaning up exactly that kind of rot, long after the fact. `ci.yml` runs fmt, clippy and a locked build on every PR, plus a `publishable` job that rejects git dependencies in the lockfile and runs `cargo publish --dry-run`. That trap already cost 0.0.22 a release cycle and only surfaces at release time otherwise. `scripts/check_upstream_drift.py` compares rmkit against rmk on two axes: release crates.io rmkit vs crates.io rmk main the working tree vs rmk's main branch They answer different questions — whether what users can install today works with the RMK they can install today, versus whether the next release will. The release axis reports but never gates, because nothing in the working tree changes its verdict; the only fix is to cut a release. Findings are cross-referenced between the axes so each one says whether it is already fixed on main or still live. It checks the rmk-config version requirement, the emitted feature names against rmk's `[features]`, parsing of every `examples/use_config` keyboard.toml with the real binary, the chip list against rmk-template, and version-mapping.json coverage. Feature names and chip options are extracted from rmkit's own source rather than copied into the script, so the checker cannot quietly fall out of sync with what it checks; a refactor that breaks an anchor raises instead. `upstream-drift.yml` runs it daily, keeping one always-current issue open while drift persists and closing it when it clears. It deliberately does not run on pull requests: it can go red because upstream changed overnight, which says nothing about the PR under review. The version.rs change is the one rustfmt violation the new fmt gate would otherwise trip on. Signed-off-by: Haobo Gu <haobogu@outlook.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`rmkit layout` added a second dependency on the rmk workspace, and with it a second way to drift: rynk-kle pins rmkit to a point in rmk's history just as rmk-config does. Track both — the checker now takes a set of crates instead of hardcoding rmk-config, reports each one's shipped version, and says which capability breaks when one falls out of step. Two wrinkles the tracking has to handle: rynk's members inherit `version.workspace = true`, so resolve against the nearest ancestor `[workspace.package]`, and older rmk releases predate rynk entirely, so a missing crate is a finding rather than a crash. Also run `cargo test` in CI, which the layout work made worth doing, and apply rustfmt to the files the new fmt gate would otherwise reject. The one non-mechanical part is a blank line in tests/cli.rs: without it rustfmt reads the comment as a continuation of the preceding trailing comment and indents it off the right margin. Signed-off-by: Haobo Gu <haobogu@outlook.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rmk-config 0.8.0 / rynk-kle 0.3.0 are what the published RMK 0.9.0 ships; rynk-kle 0.3.0 pins rmk-config =0.8.0, so the two move together. Re-add nrf52833 to the chip options now that rmk-template's 0.9 update carries its template — publish rmkit only after that PR merges.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stack 3/3 — base #14, review that one first.
rmk-template gained
esp32h2andesp32h2_splittemplates back in July, butrmkit inithad no way to pick them — the chip list never got the entry.Version goes to 0.1.0 rather than 0.0.22: the layout subcommands are a new surface, and the 0.0.x series predates the rmk-rs migration.
Release checklist once this stack lands (nothing here unblocks it on its own):
rmk-config0.7 /rynk/rynk-kleto crates.io"0.8"entry inversion-mapping.jsonto the last v0.8-compatible commit, and add a"0.9"entry