Мы понимаем, что вам нужна стабильность фреймворка Angular. Стабильность гарантирует, что переиспользуемые компоненты и библиотеки, туториалы, инструменты и освоенные практики не устареют неожиданно. Стабильность необходима для процветания экосистемы вокруг Angular.
Мы также разделяем с вами потребность Angular продолжать развиваться. Мы стремимся обеспечить, чтобы основа, на которой вы строите, непрерывно улучшалась и позволяла вам оставаться в курсе остальной веб-экосистемы и потребностей пользователей.
Этот документ содержит практики, которым мы следуем, чтобы предоставить вам передовую платформу разработки приложений в балансе со стабильностью. Мы стремимся обеспечить, чтобы будущие изменения всегда вводились предсказуемым образом. Мы хотим, чтобы все, кто зависит от Angular, знали, когда и как добавляются новые возможности, и были хорошо подготовлены, когда устаревшие удаляются.
Иногда breaking changes, такие как удаление API или возможностей, необходимы для инноваций и соответствия развивающимся лучшим практикам, меняющимся зависимостям или сдвигам веб-платформы. Эти breaking changes проходят процесс deprecation, объяснённый в нашей политике deprecation.
Чтобы сделать эти переходы максимально простыми, команда Angular берёт на себя следующие обязательства:
- Мы усердно работаем над минимизацией числа breaking changes и предоставлением инструментов миграции, когда это возможно
- Мы следуем описанной здесь политике deprecation, чтобы у вас было время обновить приложения до последних API и лучших практик
ПОЛЕЗНО: Практики, описанные в этом документе, применяются к Angular 2.0 и новее. Если вы сейчас используете AngularJS, см. Обновление с AngularJS. AngularJS — это название всех версий Angular v1.x.
Версионирование Angular
Номера версий Angular указывают уровень изменений, вводимых релизом. Использование семантического версионирования помогает понять потенциальное влияние обновления до новой версии.
Номера версий Angular состоят из трёх частей: major.minor.patch.
Например, версия 7.2.11 указывает major-версию 7, minor-версию 2 и patch-уровень 11.
Номер версии увеличивается в зависимости от уровня изменений, включённых в релиз.
| Уровень изменений | Подробности |
|---|---|
| Major release | Содержит значительные новые возможности; при обновлении ожидается некоторая, но минимальная помощь разработчика. При обновлении до нового major-релиза может потребоваться запустить скрипты обновления, отрефакторить код, выполнить дополнительные тесты и изучить новые API. |
| Minor release | Содержит новые меньшие возможности. Minor-релизы полностью обратно совместимы; помощь разработчика при обновлении не ожидается, но вы можете опционально изменить приложения и библиотеки, чтобы начать использовать новые API, возможности и функции, добавленные в релизе. Мы обновляем peer dependencies в minor-версиях, расширяя поддерживаемые версии, но не требуем от проектов обновлять эти зависимости. |
| Patch release | Низкорисковый релиз с исправлениями ошибок. Помощь разработчика при обновлении не ожидается. |
ПОЛЕЗНО: Начиная с Angular версии 7, major-версии Angular core и CLI выровнены.
Это означает, что для использования CLI при разработке Angular-приложения версии @angular/core и CLI должны совпадать.
Preview-релизы
Мы позволяем предварительно просмотреть предстоящее, предоставляя pre-релизы «Next» и Release Candidates (rc) для каждого major и minor релиза:
| Тип pre-релиза | Подробности |
|---|---|
| Next | Релиз, находящийся в активной разработке и тестировании. Next-релиз обозначается тегом релиза с идентификатором -next, например 8.1.0-next.0. |
| Release candidate | Релиз с полным набором возможностей, находящийся на финальном тестировании. Release candidate обозначается тегом релиза с идентификатором -rc, например версия 8.1.0-rc.0. |
Последняя pre-release версия документации next или rc доступна на next.angular.dev.
Частота релизов
Мы работаем над регулярным расписанием релизов, чтобы вы могли планировать и координировать обновления с продолжающейся эволюцией Angular.
ПОЛЕЗНО: Даты предлагаются как общее руководство и могут измениться.
В целом ожидайте следующий цикл релизов:
- Major-релиз каждые 6 месяцев
- 1–3 minor-релиза для каждого major-релиза
- Patch-релиз и pre-release (
nextилиrc) сборка почти каждую неделю
Такой ритм релизов даёт заинтересованным разработчикам доступ к новым возможностям, как только они полностью разработаны и прошли code review и интеграционное тестирование, сохраняя при этом стабильность и надёжность платформы для production-пользователей, которые предпочитают получать возможности после их валидации Google и другими разработчиками, использующими pre-release сборки.
Политика поддержки и расписание
ПОЛЕЗНО: Приблизительные даты предлагаются как общее руководство и могут измениться.
Расписание релизов
Расписание релизов для предстоящих версий будет объявлено в ближайшее время.
Окно поддержки
Все major-релизы обычно поддерживаются 18 месяцев.
| Этап поддержки | Сроки поддержки | Подробности |
|---|---|---|
| Active | 6 месяцев | Выпускаются регулярно запланированные обновления и патчи |
| Long-term (LTS) | 12 месяцев | Выпускаются только критические исправления и security-патчи |
Активно поддерживаемые версии
В следующей таблице приведён статус версий Angular под поддержкой.
| Версия | Статус | Выпущена | Active заканчивается | LTS заканчивается |
|---|---|---|---|---|
| ^22.0.0 | Active | 2026-06-03 | Будет объявлено | Будет объявлено |
| ^21.0.0 | LTS | 2025-11-19 | 2026-06-03 | Будет объявлено |
| ^20.0.0 | LTS | 2025-05-28 | 2025-11-19 | 2026-11-28 |
Версии Angular от v2 до v19 больше не поддерживаются.
Исправления LTS
Как общее правило, исправление рассматривается для LTS-версии, если оно устраняет одно из:
- Вновь выявленную уязвимость безопасности,
- Регрессию с начала LTS, вызванную изменением третьей стороны, например новой версией браузера.
Политика deprecation
Когда команда Angular намерена удалить API или возможность, она помечается как deprecated. Это происходит, когда API устарел, заменён другим API или иным образом прекращён. Deprecated API остаются доступными в течение фазы deprecation, которая длится минимум две major-версии (примерно один год).
Чтобы обеспечить достаточное время и ясный путь обновления, вот наша политика deprecation:
| Этапы deprecation | Подробности |
|---|---|
| Announcement | Мы объявляем deprecated API и возможности в change log. Deprecated API появляются в документации с @deprecated в соответствующей документации, что позволяет текстовым редакторам и IDE давать подсказки, если проект от них зависит. |
| Deprecation period | Когда API или возможность помечены как deprecated, они всё ещё присутствуют как минимум в следующих двух major-релизах (период не менее 12 месяцев). После этого deprecated API и возможности становятся кандидатами на удаление. Deprecation может быть объявлено в любом релизе, но удаление deprecated API или возможности происходит только в major-релизе. Пока deprecated API или возможность не удалены, они поддерживаются согласно политике поддержки LTS, то есть исправляются только критические и security-проблемы. |
| npm dependencies | Мы делаем обновления npm-зависимостей, требующие изменений в приложениях, только в major-релизе. В minor-релизах мы обновляем peer dependencies, расширяя поддерживаемые версии, но не требуем от проектов обновлять эти зависимости до будущей major-версии. Это означает, что во время minor-релизов Angular обновления npm-зависимостей внутри Angular-приложений и библиотек необязательны. |
Политика совместимости
Angular — это набор многих пакетов, подпроектов и инструментов. Чтобы предотвратить случайное использование частных API и чтобы было ясно, что покрывается описанными здесь практиками, мы документируем, что считается и что не считается нашей публичной поверхностью API. Подробности см. в Supported Public API Surface of Angular.
Чтобы гарантировать обратную совместимость Angular, мы запускаем серию проверок перед слиянием любого изменения:
- Модульные и интеграционные тесты
- Сравнение определений типов публичной поверхности API до и после изменения
- Запуск тестов всех приложений в Google, зависящих от Angular
Любые изменения публичной поверхности API делаются в соответствии с ранее описанными политиками версионирования, поддержки и deprecation. В исключительных случаях, таких как критические security-патчи, исправления могут вводить обратно несовместимые изменения. Такие исключительные случаи сопровождаются явным уведомлением в официальных каналах коммуникации фреймворка.
Политика breaking changes и пути обновления
Breaking change требует от вас работы, потому что состояние после него не обратно совместимо с состоянием до него. Редкие исключения из этого правила см. в Политике совместимости. Примеры breaking changes — удаление публичных API или другие изменения определения типов Angular, изменение тайминга вызовов или обновление до новой версии зависимости Angular, которая сама включает breaking changes.
Чтобы поддержать вас в случае breaking changes в Angular:
- Мы следуем нашей политике deprecation перед удалением публичного API
- Поддерживаем автоматизацию обновления через команду
ng update. Она предоставляет трансформации кода, которые мы часто заранее тестируем на сотнях тысяч проектов в Google - Пошаговые инструкции по обновлению с одной major-версии на другую в «Angular Update Guide»
Вы можете выполнить ng update до любой версии Angular при соблюдении следующих критериев:
- Версия, до которой вы хотите обновиться, поддерживается.
- Версия, с которой вы хотите обновиться, находится в пределах одной major-версии от версии, до которой вы хотите обновиться.
Например, можно обновиться с версии 11 до версии 12, при условии что версия 12 всё ещё поддерживается. Если нужно обновиться через несколько major-версий, выполняйте каждое обновление по одной major-версии за раз. Например, чтобы обновиться с версии 10 до версии 12:
- Обновитесь с версии 10 до версии 11.
- Обновитесь с версии 11 до версии 12.
Developer Preview
Иногда мы вводим новые API под меткой «Developer Preview». Это API, которые полностью функциональны и отполированы, но которые мы ещё не готовы стабилизировать в рамках обычной политики deprecation.
Это может быть потому, что мы хотим собрать отзывы из реальных приложений перед стабилизацией, или потому что связанная документация или инструменты миграции ещё не полностью готовы. Отзывы можно предоставить через GitHub issue, где разработчики могут делиться опытом, сообщать об ошибках или предлагать улучшения для доработки возможности.
Политики и практики, описанные в этом документе, не применяются к API, помеченным как Developer Preview. Такие API могут меняться в любое время, даже в новых patch-версиях фреймворка. Команды должны сами решать, стоят ли преимущества использования Developer Preview API риска breaking changes вне нашего обычного использования семантического версионирования.
Experimental
Эти API могут вообще не стать стабильными или претерпеть значительные изменения перед стабилизацией.
Политики и практики, описанные в этом документе, не применяются к API, помеченным как experimental. Такие API могут меняться в любое время, даже в новых patch-версиях фреймворка. Команды должны сами решать, стоят ли преимущества использования experimental API риска breaking changes вне нашего обычного использования семантического версионирования.