Ember.js Releases

Ember is committed to shipping new features without breaking your existing applications. You get Long Term Support (LTS) versions, a 6-week release cycle, and a strong commitment to Semantic Versioning.

Latest Release: 5.12.0

Create an app:


    
    npm install -g ember-cli
    

    ember new my-app-name

In addition to our latest release, we support a few other versions of Ember. To see what other versions of Ember are supported, or to read more about each release type, see long-term support (LTS), latest stable, beta, and canary releases.

Strategy

Ember is built by people who are at the front lines of building and upgrading their company's apps. They want the latest features without the burn of breaking changes, and so Ember follows a different release strategy than most other JavaScript tools.

Our goals

Add new features in a way that doesn't break existing apps, through backwards compatibility and optional feature flags
Maintain LTS (long term support) versions for 54 weeks, so that teams who upgrade their apps infrequently can keep getting security updates and bugfixes
Make a minor release about every six weeks and a major release about every eighteen months, so teams that use Ember can plan their work
Follow a public RFC (request for comments) process so that all users and companies can participate in proposing and evaluating new features
Provide automated tooling for upgrades and syntax changes
Only make breaking changes when we really, really have to
Give developers a way to test drive the latest and greatest features, on their own terms.

How Ember uses SemVer

SemVer stands for Semantic Versioning, a powerful standard across the JavaScript community that helps developers understand which versions of a library will work in their app as-is, and which versions would require changes if they wanted to upgrade.

Ember aims to ship new features in minor releases, to make breaking changes rare, and to make major releases predictable. Breaking changes force development teams to spend time researching the changes and modifying their codebase before they can upgrade. The bigger the codebase, or the more complex the app, the more time and effort it takes. Ember is committed to providing a better experience than that:

We never couple the addition of new features to breaking changes. Instead, we introduce a new feature to replace an existing feature, provide a migration path, then sometime later deprecate the old feature, and finally remove the old feature in a later major release.
Ember major versions only remove deprecated features. They never introduce new features. This means major releases are not exciting, just a predictable point where some cleanup happens.
Ember’s big releases are Editions. An Edition lands in a minor release and is therefore always backwards compatible. It represents the point where all the features we shipped in minor releases are polished, well-documented, and recommended for everyone to use. Read more here.

What SemVer means for your app

What this means in practice is, if an Ember app is version 3.4, it should keep working as-is at version 3.8. Although that version has new features, everything is backwards-compatible. What this means is, teams can do development and refactors at their own pace, all while receiving security updates and the option to use new features.

According to SemVer, releases are named according to a MAJOR.MINOR.PATCH scheme. Only MAJOR versions releases may change or remove public APIs after deprecation. MINOR versions may introduce new features so long as they are backwards compatible, and PATCH releases may include bug or security fixes.

Ecosystem tools

There are additional considerations for our support policies for other major ecosystem tools, specifically Node.js and TypeScript.

Node.js

Ember supports current stable and LTS releases for Node.js. When a version of Node.js goes out of its long-term support window, Ember also drops support for it. This is not considered a breaking change. However, release notes will always include a notice when a previously supported Node version becomes unsupported because it left its LTS period.

TypeScript

TypeScript sometimes makes breaking changes in its minor releases. Ember does its best to absorb those changes, so that you can safely upgrade Ember and TypeScript independently from each other. Specifically, Ember, Ember Data, and Ember CLI use the “rolling window” support policy defined in the latest draft of the Semantic Versioning for TypeScript Types spec (which the Ember community authored specifically to address this problem!).

In practice, this means you can always upgrade to the latest TypeScript version supported by a given Ember LTS release and then upgrade to the next Ember LTS release without needing to upgrade TypeScript again. For more details, read the spec!