Inside a single major line, Binions releases are additive and backward-compatible — so far there has been nothing to break. Across the alpha releases there has been no data migration, no config migration, and no playbook migration: existing playbooks and configuration kept working unchanged from one release to the next. Breaking changes are reserved for a new major version, and the release notes always call out anything that needs your attention.
Good to know. There is no list of breaking changes to enumerate for the current alpha — there simply haven’t been any. This page explains why upgrades inside a major are safe, and where a real breaking change can appear.
Binions follows Semantic Versioning, and the rules are deliberately conservative within a major line:
In practice this means a minor or patch upgrade inside a major is meant to be a non-event: you upgrade, the daemons restart, and your automations carry on.
Binions is event-driven: daemons coordinate by publishing and consuming events on the internal bus. Naturally, the shape of an event’s payload sometimes needs to grow as a feature matures. Binions handles this so that consumers never break:
event_version, so the platform always knows which shape a given event was written in.This is the mechanism that lets daemons of the same release stay compatible while the platform keeps improving, with no action required from you.
A breaking change — something that would require you to change a playbook, a config file, or your stored data — is reserved for a new major version (the step up to 2.0.0). A new major is also where a re-licence applies: a licence covers a whole major line, and moving up to the next major needs a new entitlement, enforced by the major-version gate.
When that day comes, you won’t have to guess what changed. The release notes and changelog spell out exactly what needs action, in plain terms, before you upgrade.
Tip. Whatever version you move to, read its release notes first. Within a major you should rarely need to change anything; across a major they tell you precisely what to do.
| Inside a major (e.g. 1.x → 1.y) | Additive and backward-compatible — no breaking changes, no migrations to perform. |
| Payload changes | Handled by event_version + upcasters; consumers always see the current shape. |
| To the next major (2.0.0) | The only place breaking changes appear — and the only place a re-licence applies. |
| Your job | Read the release notes for the version you move to; act on anything they flag. |