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: 4.8.0
Create an app:
npm install -g ember-cli
ember new my-app-name
- 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
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.
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 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!