Every Binions release ships as one matched set, so there is nothing to cross-check. All 13 daemons are built and tested together from a single workspace and carry the same version number — you never mix-and-match daemon versions on one host. This page describes the one supported configuration, why the daemons of a release stay compatible with each other, and what carries your data safely across an upgrade.
Good to know. There is no per-daemon “compatibility matrix” to look up in the usual sense. Because the whole platform moves as one version, the only rule you need is: keep every
binions-*package at the same release.
Binions is one platform at one version. When you upgrade, all of its packages move together to the new release, and that single-version state is the only configuration we support and test:
| Daemons per release | All 13, built and tested together from one workspace |
| Version skew | None — there is no per-daemon version to track separately |
| Supported state | Every installed binions-* package at the same release version |
| Your data store | Your chosen backend (PostgreSQL, SQLite, MySQL/MariaDB, MongoDB, or MSSQL) behind the database daemon + one Redis instance per daemon — carried across upgrades, never moved by them |
| Hardware | 64-bit x86 (amd64); 64-bit ARM / Raspberry Pi from the public 1.0 release* |
To confirm the rule holds on your host, list the installed packages and check that their versions match:
apt list --installed 'binions-*'Every line should report the same version. If they do, you are on a supported configuration; the post-upgrade checklist walks through this and the rest of the after-upgrade checks.
Shipping one version is the simple half of the story. The other half is making sure the daemons of a release actually speak the same language to each other — and that is enforced automatically, not left to chance:
event_version. When a payload’s shape evolves, a small upcaster lifts older payloads up to the current shape, so a consuming daemon always sees one canonical version. That is what lets the schema evolve over releases without breaking the daemons that read it.The takeaway. You don’t maintain compatibility by hand. The bus contract is guarded in testing, and payload versioning plus upcasters keep older and newer messages interoperable — you just keep the packages on one version.
An upgrade replaces the daemon binaries; it does not relocate your data. Two external stores hold the state that must survive the upgrade, and keeping them reachable is all that is required:
Both are started and ordered by systemd ahead of the daemons that depend on them, so a normal upgrade brings them back automatically. The platform’s daily backup captures the database, the per-daemon Redis state, and your configuration and playbooks — take a fresh one before any upgrade.
Before you upgrade. Make sure your database backend and each daemon’s Redis are healthy and reachable first. The upgrade does not migrate or move your data — it relies on those stores still being there. See Backup before upgrade.
* Raspberry Pi and other 64-bit ARM hardware are supported from the public 1.0 release. The current alpha packages are 64-bit x86 (amd64) only.