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.
Create an app using the latest release:
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, 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 cut a new major version (i.e. make a breaking change) 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
You might notice that although Ember has been around for a long time, it's version number is low. That is because Ember aims to ship new features in minor releases, and make major releases as rare as possible. When you see a library or framework that has many major versions, each one of those numbers represents a "breaking change." Breaking changes force development teams to spend time researching the changes and modifing 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.
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.