Release channel hierarchy

Opentrons desktop apps on Flex and OT-2 use electron-updater with three stability channels: alpha, beta, and stable (latest). Each channel reads a YAML manifest on the build CDN (alpha.yml, beta.yml, latest.yml). This page explains the traditional release model those channels reflect, why the YAML files overwrite each other the way they do, and how we still ship different build flavors on alpha and beta in parallel.

The traditional release model

Most software teams treat prerelease quality as a hierarchy of confidence:

Alpha builds go to a small, controlled audience first. The goal is early feedback and shaking out obvious defects before wider exposure.
When alpha builds reach enough stability, a beta build is published to a larger customer set. Beta is still prerelease, but it represents higher confidence than alpha.
Testing continues. Teams may ship further alpha builds for narrow validation and further beta builds for broader soak testing until both channels meet their quality bars.
When confidence is high enough, a stable release replaces prerelease channels for general availability.

That ladder is why electron-updater exposes separate channel YAMLs and a setting (generateUpdatesFilesForAllChannels) that writes lower-stability metadata when a higher-stability build publishes: a stable release should be visible to everyone who opted into beta or alpha, and a beta release should not leave alpha users stranded on an older build when beta is strictly ahead.

How YAML overwrite preserves the hierarchy

When a desktop build publishes, electron-updater updates one or more YAML files on the CDN. Higher-stability publishes overwrite metadata for lower channels:

Stable release

latest.yml
beta.yml
alpha.yml

Beta release

latest.yml (unchanged)
beta.yml
alpha.yml

Alpha release

latest.yml
beta.yml
alpha.yml

Key behavior: publishing a beta build updates both beta.yml and alpha.yml. Publishing an alpha build updates only alpha.yml. Publishing stable updates all three.

This applies on every Opentrons app host that serves desktop updater YAMLs, including Flex internal (ot3-development.builds.opentrons.com), Flex external (builds.opentrons.com), OT-2 internal (ot2-development.builds.opentrons.com), and OT-2 external (ot2.builds.opentrons.com).

Parallel flavors, not only a straight ladder

The hierarchy above describes who should receive which build through the updater. Our release process also needs flexibility: alpha and beta can carry different build flavors at the same time, not only a single line that always promotes alpha → beta → stable.

Example: a beta build may target VM isolation validation while a separate alpha build targets CRS, both active during the same development cycle. That is normal. The updater hierarchy still applies to metadata on the CDN; it does not require every alpha to become the next beta before either channel moves forward.

When both alpha and beta need fresh builds

If you intend to update both channels in the same release cycle, publish beta before alpha. A beta desktop publish overwrites alpha.yml with the beta build until an alpha publish restores alpha metadata to the intended alpha build.

That ordering rule is about updater YAML only. It does not mean alpha must always precede beta in development, and it does not replace the traditional confidence ladder. It prevents alpha-channel users from staying on a beta build after you meant to ship a distinct alpha.

Failure risk

If a beta publish succeeds but the follow-up alpha publish fails or is skipped, alpha-channel users keep seeing the beta build until alpha metadata is restored. Treat a paired cycle as incomplete until:

Beta artifacts and beta.yml point at the intended beta build
Alpha artifacts and alpha.yml point at the intended alpha build
You have verified both YAML URLs on the correct pipeline host

Stable releases

A stable desktop publish updates latest.yml, beta.yml, and alpha.yml. Users on any prerelease channel who are eligible for stable will see the stable build through the same hierarchy. Plan stable only when alpha and beta validation for that cycle is complete.

Summary

Traditional model: alpha (narrow) → beta (broader) → stable, with iteration on alpha and beta until confidence is high enough.
YAML cascade: electron-updater keeps lower channels aligned with higher stability publishes so the hierarchy is preserved on the CDN.
Parallel flavors: alpha and beta can represent different active build lines; the hierarchy governs updater metadata, not a single mandatory promotion path.
Paired cycle: when both channels need new builds, publish beta then alpha so alpha.yml ends on the correct build.
Flex and OT-2: same channel filenames and overwrite rules on internal and external app hosts.