Политика управления версиями


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


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

  • Когда выпускаются критические изменения, мы делаем major релиз, изменяя число x (например, с 15.6.2 до 16.0.0).

  • Когда выпускаются новые функции, мы делаем minor релиз, изменяя число y (например, с 15.6.2 до 15.7.0).

  • Когда выпускаются исправления ошибок, мы делаем patch релиз, изменяя число z (например, с 15.6.2 до 15.6.3).

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



Критические изменения


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

Вместо этого мы выпускаем новые функции в minor версиях. Это означает, что minor релизы часто более интересны и интригующи, чем major, несмотря на их скромное название.



Стремление к стабильности


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

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



Постепенное обновление с помощью предупреждений


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

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



Что считается критическим изменением?


Как правило, мы не изменяем номер major версии для изменений в:

  • Предупреждения в режиме разработки. Поскольку они не влияют на поведение в продакшене, мы можем добавлять новые предупреждения или изменять существующие между major версиями. Фактически это то, что позволяет нам надежно предупреждать о предстоящих критических изменениях.

  • API, начинающиеся с unstable_. API в которых мы еще не уверены предоставляются в качестве экспериментальных функций. Выпуская их с префиксом unstable_, мы можем быстрее выполнять итерации и скорее получить стабильный API.

  • Альфа и канареечные версии React. Мы предоставляем альфа-версии React как способ раннего тестирования новых функций, но нам нужна гибкость, чтобы вносить изменения в зависимости от того, что мы узнали в альфа-периоде. Если вы используете эти версии, обратите внимание, что API могут измениться до стабильной версии.

  • Недокументированные API и внутренние структуры данных. Если вы обращаетесь к внутренним именам свойств, таким как __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED или __reactInternalInstance$uk43rzhitjg, никаких гарантий нет. Вы сами по себе.

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

Тем не менее, если мы ожидаем, что изменение из этого списка вызовет широкие проблемы в сообществе, мы все равно сделаем все возможное, чтобы обеспечить постепенный путь миграции.