{"componentChunkName":"component---src-templates-docs-js","path":"/docs/faq-versioning.html","result":{"data":{"markdownRemark":{"html":"

React следует принципам семантического версионирования (semver).

\n

Это значит, что для номера версии вида x.y.z:

\n\n

Мажорные релизы могут содержать новые возможности. Каждый релиз может содержать исправления ошибок.

\n

Минорный релиз — самый распостранённый тип релизов.

\n

Обратно несовместимые изменения

\n
\n

Данная политика версионирования не относится к предварительным сборкам в каналах следующих и экспериментальных версиях. Узнать подробнее о предварительных версиях.

\n
\n

Обратно несовместимые изменения неудобны для всех, поэтому мы стараемся минимизировать количество мажорных релизов. Например, React 15 был выпущен в апреле 2016 года, а React 16 — в сентябре 2017 года. React 17 ожидается где-то в 2020 году.

\n

Вместо этого мы выпускаем новые возможности в минорных релизах. Это значит, что минорные релизы зачастую более интересны, чем мажорные, несмотря на порядковый номер версии.

\n

Ответственное отношение к стабильности

\n

Изменяя React, мы стараемся упростить изучение новых возможностей. Кроме этого, мы стараемся сохранить работу старых API, даже если требуется их перенос в отдельный пакет. Например, мы отказались от примесей несколько лет назад, но они до сих пор поддерживаются через create-react-class и многие проекты продолжают их использовать в стабильном, устаревшем коде.

\n

Больше миллиона разработчиков React используют, поддерживая миллионы компонентов. Только в кодовой базе Facebook более 50 000 React-компонентов. Всё это обязывает нас делать обновления до новых версий как можно проще. Если мы не предоставим возможности для обновления, люди застрянут на старых версиях. Мы тестируем наши пути обновления прямо в Facebook — если наша команда из 10 человек может обновить более 50 тысяч компонентов, мы думаем, что с этим справятся и другие React-разработчики. Во многих случаях для обновления синтаксиса компонентов мы пишем скрипты автоматизации, которые выкладываем в открытый доступ для всеобщего использования.

\n

Постепенное обновление через предупреждения

\n

Сборки в режиме разработки в React включают множество полезных предупреждений. Когда возможно, мы добавляем предупреждения для будущих обратно несовместимых изменений. Таким образом, если ваше приложение не показывает предупреждений в консоли в последнем релизе, значит оно готово к следующей мажорной версии. Это позволяет вам обновлять приложение компонент за компонентом по одиночке.

\n

Предупреждения в режиме разработки не влияют на то, как исполняется ваше приложение. Таким образом, вы можете быть уверены, что ваше приложение будет вести себя одинаково в режиме разработки и продакшен-режиме. Разница лишь в том, что продакшен-сборка не будет показывать предупреждения в консоли, что, к тому же, более производительно. (Если вы вдруг заметили предупреждение в продакшен-режиме, откройте ишью.)

\n

Что считается обратно несовместимым изменением?

\n

Как правило, мы не повышаем мажорную версию для следующих изменений:

\n\n

Наша политика разработана, чтобы быть практичной. Мы не хотим создавать вам головную боль. Если бы мы поднимали мажорную версию слишком часто, то доставили бы множество проблем всему сообществу. И это бы не позволило улучшать React так быстро, как нам хотелось.

\n

Если мы думаем, что изменения могут вызвать проблемы в сообществе, мы постараемся сделать всё возможное, чтобы предоставить плавный переход от старой версии к новой.

\n

Если минорный релиз не содержит новых возможностей, почему это не патч релиз?

\n

Иногда минорный релиз может не включать новых возможностей. Это допускается семантическим версионированием, в котором говорится, что ”[минорная версия] МОЖЕТ быть увеличена в случае реализации новой функциональности или существенного усовершенствования в приватном коде. Версия МОЖЕТ включать изменения, характерные для патчей.»

\n

Тем не менее, возникает вопрос, почему эти версии не являются патчами.

\n

Ответ прост: любое изменение в React (как и в любой другой программе) несёт определённый риск непредвиденных ситуаций. Представьте ситуацию, в которой выпуск патч-релиза, исправляющий один баг, случайно вносит новый. Подобное не только негативно влияет на разработчиков, но и подрывает их уверенность в будущих патч-релизах. Особенно печально, если исправлялся баг, редко встречающийся на практике.

\n

У нас довольно хороший опыт в выпуске релизов React без багов, но патч-релизы имеют более высокую планку надёжности, поскольку большинство разработчиков предполагают, что они могут быть приняты без негативных последствий.

\n

По этим причинам мы используем патч-релизы только для критических багов и уязвимостей в безопасности.

\n

Если в релиз включены несущественные изменения — такие как внутренний рефакторинг, изменения деталей реализации, улучшение производительности или исправление мелких багов — мы увеличим минорную версию, даже если ничего нового нет.

","frontmatter":{"title":"Политика версионирования","next":null,"prev":null},"fields":{"path":"content/docs/faq-versioning.md","slug":"docs/faq-versioning.html"}}},"pageContext":{"slug":"docs/faq-versioning.html"}},"staticQueryHashes":[]}