Our semver, timed-release cycle and deprecation policy currently applies to these npm packages:
One intentional omission from this list is
@angular/compiler, which is currently considered a low level api and is subject to internal changes. These changes will not affect any applications or libraries using the higher-level apis (the command line interface or JIT compilation via
@angular/platform-browser-dynamic). Only very specific use-cases require direct access to the compiler API (mostly tooling integration for IDEs, linters, etc). If you are working on this kind of integration, please reach out to us first.
@angular/bazel is currently an Angular Labs project and not covered by the public API guarantees.
Additionally only the command line usage (not direct use of APIs) of
@angular/compiler-cli is covered.
Other projects developed by the Angular team like angular-cli, Angular Material, will be covered by these or similar guarantees in the future as they mature.
Within the supported packages, we provide guarantees for:
@angular/core) and testing entry point (e.g.
bundles/directory of our npm packages (e.g.
We explicitly don’t consider the following to be our public API surface:
/bundles/*and other documented package entry-points.
private, or prefixed with underscore (
_), barred latin o (
ɵ), and double barred latin o (
NgModuleFactoryinstances exported from generated code is guaranteed)
Our peer dependencies (e.g. TypeScript, Zone.js, or RxJS) are not considered part of our API surface, but they are included in our SemVer policies. We might update the required version of any of these dependencies in minor releases if the update doesn’t cause breaking changes for Angular applications. Peer dependency updates that result in non-trivial breaking changes must be deferred to major Angular releases.