| name | version-bump |
| description | Firmware-change discipline for Raiden Pico — ANY change to the firmware (src/*.c, src/*.pio, include/*.h that alters the built raiden_pico.uf2's behavior or output) MUST bump the firmware version string in the SAME change. The version is what the VERSION command prints, in src/command_parser.c. Invoke whenever you edit firmware source, or are about to build + flash a firmware change. |
Every firmware change bumps the version
The firmware version is the one string a user (and host tooling) reads to know
what is actually on the chip. If the binary's behavior changes but the version
doesn't, a freshly-flashed device is indistinguishable from the old build — you
can't tell whether a fix or feature is really on the part. This bites hardest on
this project because flashing is a manual drag-drop dance; the VERSION readout
is the only confirmation the right firmware landed.
Rule: any change that alters the firmware's behavior or output MUST bump the
version in the SAME change (same commit as the code).
Where the version lives
A single string printed by the VERSION command:
uart_cli_send("Raiden Pico Glitcher vX.Y\r\n");
Find it: grep -n 'Glitcher v' src/command_parser.c. Keep the Raiden Pico Glitcher v prefix — host tooling and tests/conftest.py gate on the word
"Raiden", and STATUS/scripts surface this string.
How to bump
- Minor (
vX.Y → vX.(Y+1)) for a new feature/command or a behavior change
(new CLI command, new mode, a refactor that changes timing/behavior/output).
- Patch (add a
.Z field if needed) for a small bug fix.
- One bump per logical change/PR — don't double-bump for the same change.
Bump from the version that is LIVE on
main (committed/pushed), not your local
working-tree value — if nothing's been pushed since the last release, the whole
uncommitted batch is one bump (don't re-increment for each edit/flash cycle).
Also update the CHANGELOG
Every version bump MUST add a matching entry to CHANGELOG.md in the same
change — that's the only place changes are tracked outside commit messages. Add a
## [X.Y] — <date> section with Added / Changed / Fixed / Removed
subsections as appropriate. Keep it user-facing (what the device now does), not a
code diff.
Checklist
When NOT to bump
- Docs-only changes (
README.md, *.md), host-side Python (scripts/, tests/),
or pure comment/whitespace edits that don't change behavior or output — these
don't alter the firmware a user runs, so the version stays.
- If unsure: does the change alter what the device does or prints? If yes, bump.
