pub const PROTOCOL: Version;Expand description
The protocol version this SDK speaks.
Independent of the daemon’s version, which is the whole point of FR-049: an
addon is built against an SDK, not against a daemon, and the two ship
separately. major differing means incompatible, and the daemon refuses
rather than loading — FR-049 again, with a message naming the fix, the same
rule the UI–daemon handshake already follows.
§1.1 — device-resolved actions
Description::device_actions was added (ADR-0021). Minor, because
Version::compatible_with compares majors, the field is omitted when
empty, and an addon that declares none puts not one new byte on the wire.
A major bump would refuse every 1.1 addon on a 1.0 daemon — the shipped ones,
and every third-party addon that declares nothing of the kind — to defend
against one field.
Additive on the wire is not additive in meaning, and the version number cannot carry the difference. Two things carry it instead, and neither is optional:
- A daemon that reads this field must refuse an action it cannot
represent, naming it, rather than reading it as something else. The
refusal is per action: the addon stays in the registry with that one row
reported unusable. Failing the handshake instead would leave the addon
nowhere but a log line, which is a Principle IV collapse — and it is why
KeystrokeDeclcarriesKeystrokeDecl::Unknownrather than failing the parse of the wholeDescription. - A daemon built against 1.0 does not know the field exists. Serde drops what
it does not recognise, so it will send
Request::Performfor an action whose author never wrote aperformarm.runanswers that itself with a failure naming the cause, rather than letting it fall through toNoSuchAction, which would send the user looking for a missing action that is right there in the list.