Releases

A release is one version of your JavaScript bundle plus metadata, published to one deployment. The server labels releases v1, v2, v3 and so on, per deployment, in the order they arrive.

What a release carries

The package itself is immutable: its contents, packageHash (a SHA-256 of the contents), and size never change. Around it lives metadata:

• appVersion: the semver version or range of app binaries this release targets, for example 1.2.0 or >=1.2.0 <2.0.0.
• isMandatory: the SDK installs mandatory updates with a more aggressive default install mode.
• isDisabled: a disabled release is not served to any device.
• rollout: the percentage of devices eligible for the release. See Staged rollout.
• description: free text shown in history and available to the SDK’s update dialog.
• releaseMethod: how the release came to be. Upload for a direct release, Promote or Rollback for releases created by those operations, which also record the original label they came from.

Changing metadata after the fact

aether patch edits the mutable fields of an existing release without shipping new code:

aether patch MyApp Staging -l v3 --description "Fixes the crash on login" -m true

Without -l it targets the latest release. You can change the description, the mandatory and disabled flags, the target binary version, and raise the rollout percentage.

Rules the server enforces

• Releasing the exact same bundle twice into the same deployment fails with a duplicate error. Pass --noDuplicateReleaseError to turn that into a warning.
• While the latest release has an unfinished rollout, you cannot release a new package. Finish it first: aether patch MyApp Staging -r 100.
• Release history is retained per your plan (14, 90, or 365 days). See Plans, quotas, and MAD.