Versioning and compatibility
One version
Every crate, the taktwerk binary, the desktop app and the Python package carry one version
number, and a release tag vX.Y.Z (SemVer) releases them together: the CLI archives, the
workbench installers and a SHA256SUMS of every file, with the release’s section of
CHANGELOG.md as its notes. The release refuses a tag that differs from the crates’ or the
app’s version. taktwerk --version prints it; run.json, campaign.json, a bundle manifest
and GET /api/info record it.
The workbench deploys the engine of its own version, which its installer carries for every device architecture, so the app and the engines it deploys never disagree on a format.
What is numbered
Formats exchanged between processes or kept on disk carry a number of their own, checked by the reader:
| number | where | checked by |
|---|---|---|
format 1 | run.json of a run record and the OPC UA pull encoding | taktwerk record refuses an engine of another recorder format |
format 1 | a bundle manifest, .taktwerk/manifest.json | the agent refuses a manifest of another format |
agent_api 1 | every JSON document of taktwerk agent | the host refuses an agent of another interface |
format 1 | a campaign’s campaign.json and each run’s status.json | written; a resume compares spec hashes |
The project file, the scenario and campaign files and a raw package’s descriptor carry no number; the project, scenario and campaign files refuse unknown keys.
Versions side by side
- On a device every engine version lives in
bin/taktwerk-<version>; a release links the one its manifest names, so bundles on one device may run different versions and a rollback returns to the release’s own engine. A deploy installs a missing engine only after it reports the host’s version. - A run record names the engine’s version in
run.json. - A campaign’s spec hash covers the taktwerk version: after an upgrade
--writeruns every run again.