Angular versioning and releases

Angular recognize that you need stability from the Angular framework. Stability ensures that reusable components and libraries, tutorials, tools, and learned practices don't become obsolete unexpectedly. Stability is essential for the ecosystem around Angular to thrive.

Angular also share with you the desire for it to keep evolving. They strive to ensure that the foundation on top of which you are building is continuously improving and enabling you to stay up-to-date with the rest of the web ecosystem and your user needs.

This tutorial contains the practices that they follow to provide you with a leading-edge app development platform, balanced with stability. They strive to ensure that future changes are always introduced in a predictable way. They want everyone who depends on Angular to know when and how new features are added, and to be well-prepared when obsolete ones are removed.

The practices described in this tutorial apply to Angular 2.0 and later. If you are currently using AngularJS, see Upgrading from AngularJS. AngularJS is the name for all v1.x versions of Angular.

Angular versioning

Angular version numbers indicate the level of changes that are introduced by the release. This use of semantic versioning helps you understand the potential impact of updating to a new version.

Angular version numbers have three parts: major.minor.patch. For example, version 7.2.11 indicates major version 7, minor version 2, and patch level 11.

The version number is incremented based on the level of change included in the release.

• Major releases contain significant new features, some but minimal developer assistance is expected during the update. When updating to a new major release, you may need to run update scripts, refactor code, run additional tests, and learn new APIs.
• Minor releases contain new smaller features. Minor releases are fully backward-compatible; no developer assistance is expected during update, but you can optionally modify your apps and libraries to begin using new APIs, features, and capabilities that were added in the release. We update peer dependencies in minor versions by expanding the supported versions, but we do not require projects to update these dependencies.
• Patch releases are low risk, bug fix releases. No developer assistance is expected during update.

If you are updating within the same major version, then you can skip any intermediate versions and update directly to the targeted version. For example, if you want to update from 7.0.0 to 7.2.11, then you can update directly; you do not need to update from 7.0.0 to 7.1.0 before updating to 7.2.11.

If you are updating from one major version to another, it is recommended that you don't skip major versions. Follow the instructions to incrementally update to the next major version, testing and validating at each step. For example, if you want to update from version 5.x.x to version 7.x.x, we recommend that you update to the latest 6.x.x release first. After successfully updating to 6.x.x, you can then update to 7.x.x.

Release frequency

We work toward a regular schedule of releases, so that you can plan and coordinate your updates with the continuing evolution of Angular.

In general, you can expect the following release cycle:

• A major release every 6 months
• 1-3 minor releases for each major release
• A patch release almost every week

Angular promises backward compatibility whose primary is to ensure that changes in the core framework and tooling don't break the existing ecosystem of components and applications and don't put undue upgrade/migration burden on Angular application and component authors.

Support policy and schedule

All our major releases are supported for 18 months.

• 6 months of active support, during which regularly scheduled updates and patches are released.
• 12 months of long-term support (LTS), during which only critical fixes and security patches are released.

Deprecation practices

Sometimes "breaking changes", such as the removal of support for select APIs and features, are necessary to innovate and stay current with new best practices, changing dependencies, or changes in the (web) platform itself.

To make these transitions as easy as possible, we make two commitments to you:

• We work hard to minimize the number of breaking changes and to provide migration tools when possible.
• We follow the deprecation policy described here, so you have time to update your apps to the latest APIs and best practices.

To help ensure that you have enough time and a clear path to update, this is our deprecation policy:

• We announce deprecated features in the change log.
• When we announce a deprecation, we also announce a recommended update path.
• We support existing use of a stable API during the deprecation period, so your code will keep working during that period.
• We support each deprecated API for at least two subsequent major releases, which means at least 12 months after deprecation.
• We only make peer dependency updates that require changes to your apps in a major release. In minor releases, we update peer dependencies by expanding the supported versions, but we do not require projects to update these dependencies until a future major version.

Public API surface

Angular is a collection of many packages, sub-projects, and tools. To prevent accidental use of private APIs-and so that you can clearly understand what is covered by the practices described here-we document what is and is not considered our public API surface.

Angular Labs

Angular Lab is an initiative to cultivate new features and iterate on them quickly. Angular Labs provides a safe place for exploration and experimentation by the Angular team.

Angular Labs projects are not ready for production use, and no commitment is made to bring them to production.

Previous: Testing
Next: Updating your Angular projects