Canonical log
GitHub Releases
Ember's stable public release history lives on the repository releases page.
Instead of duplicating or guessing release history inside the marketing site, this page points to the canonical GitHub Releases log and explains how Ember versions, installers, and update checks are delivered.
Stable strategy
Canonical log
GitHub Releases
Ember's stable public release history lives on the repository releases page.
Installer assets
Windows + macOS
Latest release delivery is mapped to a Windows setup executable and a macOS disk image.
Update checks
Background notifications
Installed builds check for updates in the background and notify users when a new version is available.
Integrity
SHA256 verification
Release metadata resolves a SHA256 digest before the latest installer is served.
The marketing site stays honest by linking to the public release ledger instead of recreating a version table that can drift.
This page stays intentionally stable: for version-by-version notes, installer assets, and tags, GitHub Releases is the canonical public surface.
Backend download handling expects `Ember.dmg` for macOS and a versioned `Ember-Setup-<version>.exe` asset for Windows.
Ember checks for updates in the background, then surfaces a newer version when one is available.
Use these links when you want tagged builds, release notes, or repository context without depending on a website-side mirror.
Release handling in the backend and app is explicit about asset names, digest checks, and version metadata.
Latest-download metadata prefers GitHub asset digests and falls back to the historical `SHA256:` release-note format when needed.
The latest-download and update-check routes require a valid license key, while update checks themselves do not consume credits.
Packaged Ember builds use build-time release metadata, while development checkouts fall back to a `-dev` version suffix.
What users can expect