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

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

Це означає, що для номера версії виду x.y.z:

• При випуску виправлень помилок, ми робимо патч-реліз, змінюючи число z (наприклад, з 15.6.2 до 15.6.3).
• При випуску нових можливостей або несуттєвих виправлень, ми робимо мінорний реліз, змінюючи число y (наприклад, з 15.6.2 до 15.7.0).
• При випуску зворотно несумісних змін, ми робимо мажорний реліз, змінюючи число x (наприклад, з 15.6.2 до 16.0.0).

Мажорні релізи можуть містити нові можливості. Кожен реліз може містити виправлення помилок.

Мінорний реліз — найпоширеніший тип релізів.

Ця Політика версіонування не відноситься до попередніх збірок в каналах наступних і експериментальних версій. Дізнайтися більше про попередні випуски.

Зворотно несумісні зміни

Зворотно несумісні зміни незручні для всіх, тому ми намагаємося мінімізувати кількість мажорних релізів. Наприклад, React 15 був випущений у квітні 2016 року, а React 16 — у вересні 2017 року. React 17 очікується десь у 2020 році.

Замість цього ми випускаємо нові можливості в мінорних релізах. Це означає, що мінорні релізи найчастіше більш цікаві, ніж мажорні, незважаючи на порядковий номер версії.

Відповідальне ставлення до стабільності

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

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

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

Збірки в режимі розробки в React включають безліч корисних попереджень. Коли можливо, ми додаємо попередження для майбутніх зворотно несумісних змін. Таким чином, якщо ваш додаток не показує попереджень в консолі в останньому релізі, значить воно готове до наступної мажорної версії. Це дозволяє вам оновлювати додаток компонент за компонентом поодинці.

Попередження про розробку не вплинуть на поведінку вашої програми під час виконання. Таким чином, ви можете бути впевнені, що ваш додаток буде вести себе однаково в режимі розробки і продакшн-режимі. Різниця лише в тому, що продакшн-збірка не буде показувати попередження в консолі і що вона більш ефективна. (Якщо ви раптом помітили попередження в продакшн-режимі, відкрийте іш’ю в репозиторії React.)

Що вважається зворотно несумісною зміною?

Як правило, ми не підвищуємо мажорну версію для наступних змін:

• Попередження для розробників. Оскільки вони не впливають на поведінку в продакшн-режимі, ми можемо додавати або змінювати існуючі попередження між мажорними версіями. Це дозволяє нам заздалегідь попереджати про нові мажорні зміни.
• APIs з приставкою unstable_. Вони додають експериментальні можливості, в API яких ми не впевнені до кінця. Випускаючи такі можливості з приставкою unstable_ ми можемо їх оновлювати і переходити до стабільного API швидше.
• Альфа і канаркові версії React. Альфа-версії React дозволяють спробувати нові можливості раніше. Ми можемо вносити в них зміни на основі зворотного зв’язку, отриманого в період альфа-тестування. Якщо ви використовуєте такі версії, майте на увазі, що API може змінитися в стабільній версії.
• Недокументовані API і внутрішні структури даних. Ми не гарантуємо працездатність коду в разі використання __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED or __reactInternalInstance$uk43rzhitjg або інших внутрішніх змінних.

Наша політика розроблена, щоб бути практичною. Ми не хочемо створювати вам головний біль. Якби ми піднімали мажорну версію занадто часто, то доставили б безліч проблем всій спільноті. І це б не дозволило покращувати React так швидко, як нам хотілося.

Якщо ми думаємо, що зміни можуть викликати проблеми в спільноті, ми постараємося зробити все можливе, щоб забезпечити плавний перехід від старої версії до нової.

Якщо мінорний реліз не містить нових можливостей, чому це не патч реліз?

Іноді мінорний реліз може не включати нових можливостей. Це допускається семантичним версіонуванням, в якому говориться, що ”[мінорна версія] МОЖЕ бути збільшена в разі реалізації нової функціональності або істотного удосконалення в приватному коді. Версія МОЖЕ включати зміни, характерні для патчів.”

Однак виникає питання, чому ці версії не є патчами.

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

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

З цих причин ми використовуємо патч-релізи тільки для критичних багів і вразливостей в безпеці.

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