Release section purpose
OpenHaldex now has a dedicated release area so version management is explicit and user-facing. Instead of
forcing users to parse a rolling root README changelog, each tagged version gets a direct page with structured
release notes, asset links, install methods, and known-issue context. This makes field updates safer and
support conversations easier because everyone can reference the same versioned document.
The release hub is designed for two audiences:
- Users who need a reliable way to flash a specific firmware/filesystem pair.
- Developers and maintainers who need reproducible release artifacts and changelog traceability.
Current release index
As additional releases are published, append them here in descending order. Every release row should include
a dedicated release note page and installer link.
Firmware asset layout
This release structure assumes versioned firmware assets live under `docs/release/firmware//` and
matching ESP Web Tools manifests live under `docs/release/manifests/`. For each version, keep naming stable
and machine-readable so install buttons and scripts do not require per-version code edits.
docs/release/
firmware/
v0.9.3-beta/
bootloader.bin
partitions.bin
firmware.bin
littlefs.bin
checksums.txt
manifests/
v0.9.3-beta.json
This layout allows users to flash any release they choose while maintainers keep one predictable mapping from
version -> manifest -> binaries.
Installer strategy
The web installer page is intentionally separate from release notes. Release notes communicate what changed and
why. The installer page handles the operational action of flashing binaries. This separation keeps each page
focused, reduces accidental installs from users who have not reviewed notes, and makes it easier to support
users on older versions.
Recommended install flow:
- Open the selected version notes and read breaking/known-issue sections.
- Confirm hardware target and current device state.
- Use the web installer for that exact version manifest.
- Verify post-flash status and UI behavior before road testing.
Legacy notes migration
The root `README.md` technical changelog currently contains historical engineering notes up to earlier UI
phases. To avoid losing that context, those notes are mirrored in a release archive page and treated as
pre-structured history. This lets the project move from a rolling changelog model to a release-per-page model
without breaking attribution or technical continuity.
Release publishing checklist
- Create Git tag and release entry (for this cycle: `v0.9.3-beta`).
- Export and upload `bootloader.bin`, `partitions.bin`, `firmware.bin`, and `littlefs.bin`.
- Update the matching manifest JSON with correct paths and offsets.
- Publish release note page with highlights, known issues, and rollback notes.
- Add/verify release row in this hub and installer page listing.
- Test web installer flow on a clean device and an upgrade device.
- Update changelog references in docs and subreddit announcement links.
Try the OpenHaldex Firmware Demo
Preview the real OpenHaldex firmware UI in your browser with simulated live CAN traffic and interactive pages for tuning, diagnostics, logs, setup, and OTA workflows.
Open firmware demo