Flex coordinated tagging

Every Flex release uses coordinated tags across opentrons, oe-core, and ot3-firmware. The app tag is authoritative; robot OS matches it; firmware uses the same ot3@* tag internally or an ex* coordination tag externally, plus a colocated integer vN on the same commit.

Six common flavors: the internal and external pipelines, each with stable, beta, or alpha stability. At one semver base, alpha and beta are independent lanes with separate counters. See also Release channel hierarchy for how alpha, beta, and stable updater channels interact on Flex and OT-2.

Firmware coordination tag

Firmware integer vN

Robot OS (oe-core)

App (opentrons)

Internal pipeline stable

Internal pipeline beta

Internal pipeline alpha

External pipeline stable

External pipeline beta

External pipeline alpha

Rules (all flavors)

The opentrons tag defines the coordinated release. Builds fail if a required tag is missing; there is no “latest tag” fallback (oe-core #329).
oe-core always uses the same stack tag as the app.
ot3-firmware internal: same ot3@* as the app. External: map v* → ex* (never put semver vX.Y.Z on firmware; that collides with integer vN discovery).
Every firmware release commit needs exactly one integer vN on the same commit. Reuse vN when the firmware commit did not change.
A coordination tag on an unchanged commit is normal: it marks participation in that release, not necessarily new firmware code.

Tag push order

When creating tags, push in this order: ot3-firmware (if needed), oe-core (if needed), opentrons (app, always last). Run just validate-release-tags --tag <app-tag> before pushing the app tag.

Verify locally

just validate-release-tags --tag ot3@8.5.0-beta.1
just validate-release-tags --tag v10.0.0-alpha.2