Releases & Versioning

A release record contains a version label and release notes. Publishing that record makes notes available; it does not upload, replace or deploy an application binary.

Create release notes

1. •Open Releases and select an app you own.
2. •Enter a version and notes describing actual user-visible changes.
3. •Choose alpha, beta or production, and a rollout percentage between 0 and 100.
4. •Save the release. Newly created records have review status.
5. •Use the promotion action when you intend to publish the notes. Promotion sets the record to production/published.

This example is a request shape for an authorized account, not a command to run against a production app without approval:

{
  "version": "1.2.3",
  "release_notes": "Fixed the export dialog.",
  "track": "beta",
  "rollout_percentage": 10
}

The create path is POST /apps/{id}/releases. Listing releases uses GET /apps/{id}/releases; promotion and rollout updates use PUT /apps/{id}/releases/{release_id}/promote and PUT /apps/{id}/releases/{release_id}/rollout.

Limits and troubleshooting

Use semantic versioning as an authoring convention. The handler bounds version labels to 1–64 characters; it does not enforce increasing semantic versions per channel. Notes are bounded to 10,000 characters. Only the app owner or an administrator can manage records.

Rollout percentage is stored metadata. It is not evidence of percentage-based binary distribution, crash monitoring or a canary deployment. No rollback endpoint is documented in this interface. To replace an app build, use the app editor and the scanned submission workflow in Uploading Apps.

If an update fails, confirm the selected app belongs to your account, use a supported track and check the percentage. Public GET /apps/{id}/whats-new returns published notes for approved apps; a draft or pending app may have no public notes.

Next

See Analytics and Listing Best Practices.