Release and distribute
Release begins after packaging. At this stage you already have an artifact manifest. The release workflow prepares metadata, checks provider requirements, uploads or submits the artifact, and records what happened.
The release loop
Step | Command shape | What it proves |
|---|---|---|
Validate release content | fission release-content validate ... | Notes, screenshots, privacy files, review material, and store metadata exist and match provider requirements. |
Check provider readiness | fission readiness distribute ... | Credentials, provider tools, package identity, tracks, and artifact shape are valid before upload. |
Distribute | fission distribute ... or fission publish ... | The manifest-backed artifact is uploaded or submitted to the selected provider. |
Keep the receipt | target/fission/distribution/... | The team can later prove which asset, hash, provider id, URL, or rollout state was produced. |
Release commands should fail with diagnosable errors. Missing credentials, expired auth, invalid tracks, absent screenshots, and provider rejections should be safe to fix and retry.
Pick the provider page
Destination | Start here | Common artifacts |
|---|---|---|
GitHub release assets | installers, binaries, archives, APK/AAB/IPA, static site zip | |
Static website hosting | static site manifest | |
Mobile and desktop stores | AAB, IPA, MSIX, store metadata | |
Container registry | static or server Docker image | |
Buckets and object stores | arbitrary package assets and static files | |
Notes, screenshots, review files | provider metadata and human-facing release material |
Use Release lifecycle details when you need the full command model and provider lifecycle rather than one provider path.
Keep fission.toml readable
fission.toml is the root manifest. Put stable facts there: app id, version, target declarations, provider references, release tracks, and paths to release-content files.
Do not put full release notes, long localized store descriptions, screenshot inventories, or review attachments directly into fission.toml. Put those in referenced files so people can review them and reuse them across CI.
Receipts matter
A release receipt records provider ids, URLs, deployment ids, uploaded bytes, artifact hashes, release status, and follow-up steps. Keep receipts in CI artifacts or release records. They answer practical questions later: what was uploaded, where did it go, which hash did we publish, and what did the provider return?
Next steps
If you do not have an artifact manifest yet, go back to Build and package. If you are preparing a store or public release, start with Release content before upload.
Fission
A cross-platform, GPU-accelerated user interface framework for Rust. MIT licensed.
Copyright (c) 2026 Fission
Ready to use today. Widget APIs are expected to remain stable; some runtime and shell APIs may change before 1.0.0.
Fission 0.7.0