Release Process
Edit on GitHubHow firmware releases happen: version numbering, the changelog, the release checklist, and what users should do before updating.
Release Process
A release is a promise: this version is tested, documented and flashable by anyone. The process exists to keep that promise honest.
Version numbering
The firmware follows semantic versioning (see Changelog):
| Bump | When |
|---|---|
| Major | Breaking config or payload format (v4 to v5) |
| Minor | New features, backward compatible |
| Patch | Bug fixes |
The release checklist
- All CI checks green (see CI/CD).
- The changelog updated with the new entries.
- The wiki’s version-specific pages reviewed (config format, migration notes).
- A bench test pass on the release candidate (see Two Beacon Bench Test).
- Tag the release; attach the firmware binary.
What users should do
Before updating:
- Read the changelog for the target version, especially migration notes.
- Back up your configuration (serial
config dump, see Serial Monitor Guide). - Flash, then verify: boot log clean, config loaded, one test burst decoded.
Rollback
If a release misbehaves:
- Flash the previous version.
- Factory reset (see Factory Reset and Recovery) to clear any new-format config.
- Report the problem (see Reporting Issues).
Related pages
- Changelog for the history
- Version Selection for choosing a version
- Software Build Process for building from source