Політика версій

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

Молодші релізи є найпоширенішим типом випуску.

Основні зміни

Різкі зміни незручні для всіх, тому ми намагаємося мінімізувати кількість старших релізів - наприклад, React 15 вийшов у квітні 2016 року, React 16 - у вересні 2017 року, а React 17 - у жовтні 2020 року.

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

Прихильність до стабільності

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

Понад мільйон розробників використовують React, колективно підтримуючи мільйони компонентів. Лише у кодовій базі Facebook є понад 50 000 React-компонентів. Це означає, що нам потрібно максимально спростити перехід на нові версії React; якщо ми зробимо великі зміни без шляху міграції, люди застрягнуть на старих версіях. Ми тестуємо ці шляхи оновлення на самому Facebook - якщо наша команда з менш ніж 10 людей може оновити 50 000+ компонентів самостійно, ми сподіваємося, що оновлення буде доступним для будь-кого, хто використовує React. У багатьох випадках ми пишемо автоматизовані скрипти для оновлення синтаксису компонентів, які потім включаємо у відкритий реліз для всіх бажаючих.

Поступове оновлення за допомогою попереджень

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

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

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

Загалом, ми не змінюємо номер основної версії для змін до:

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

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

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

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

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

Втім, виникає питання, чому ці випуски не випущено у вигляді патчів.

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

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

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

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

Всі канали випуску

React покладається на процвітаючу спільноту з відкритим вихідним кодом, що дозволяє надсилати повідомлення про проблеми, відкривати запити на додавання та надсилати RFC. Щоб заохотити зворотній зв'язок, ми іноді ділимося спеціальними збірками React, які включають невипущені функції.

Кожен з каналів релізу React призначений для окремого випадку використання:

• Latest - для стабільних, semver-релізів React. Це те, що ви отримуєте, коли встановлюєте React з npm. Це канал, який ви вже використовуєте сьогодні. Користувацькі застосунки, які споживають React безпосередньо, використовують цей канал.
• Canary відстежує основну гілку сховища коду React. Вважайте їх кандидатами на реліз для наступної версії. Фреймворки або інші кураторські установки можуть використовувати цей канал із закріпленою версією React. Ви також можете використовувати Canaries для тестування інтеграції між React та сторонніми проектами.
• Experimental містить експериментальні API та можливості, які недоступні у стабільних релізах. Вони також відстежують основну гілку, але з увімкненими прапорами додаткових можливостей. Використовуйте їх для тестування майбутніх можливостей до їх релізу.

Усі випуски публікуються на npm, але лише в останньому використовується семантичне керування версіями. Попередні випуски (у каналах Canary та Experimental) мають версії, згенеровані на основі хешу їхнього вмісту та дати комміту, наприклад, 18.3.0-canary-388686f29-20230503 для Canary та 0.0.0-experimental-388686f29-20230503 для Experimental.

Канали Latest та Canary офіційно підтримуються для користувацьких застосунків, але з різними очікуваннями:

• Останні випуски слідують традиційній моделі semver.
• Канонічні релізи мають бути закріплені і можуть містити викривлені зміни. Вони існують для кураторів (наприклад, фреймворків), які хочуть поступово випускати нові можливості React та виправлення за власним графіком випуску.

Експериментальні випуски надаються лише з метою тестування, і ми не надаємо жодних гарантій, що поведінка не зміниться між випусками. Вони не відповідають протоколу semver, який ми використовуємо для випусків з пакунка Latest.

Публікуючи попередні випуски до того самого реєстру, що й стабільні випуски, ми можемо скористатися багатьма інструментами, які підтримують робочий процес npm, зокрема unpkg та CodeSandbox.

Останній канал

Latest - канал, який використовується для стабільних релізів React. Він відповідає тегу latest у npm. Це рекомендований канал для всіх React-застосунків, які постачаються реальним користувачам.

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

Канальний канал

Канал Canary - це канал попередніх версій, який відстежує основну гілку репозиторію React. Ми використовуємо попередні релізи в каналі Canary як кандидатів на реліз для каналу Latest. Ви можете думати про Canary як про підмножину каналу Latest, яка оновлюється частіше.

Ступінь змін між останнім релізом Canary і останнім релізом Latest приблизно такий самий, як і між двома молодшими напіврелізами. Однак канал Canary не відповідає вимогам семантичного керування версіями.Ви маєте очікувати, що між послідовними релізами у каналі Canary іноді відбуватимуться різкі зміни.

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

Випуски мовою Canary публікуються з тегом canary у npm. Версії генеруються з хешу вмісту збірки та дати фіксації, наприклад, 18.3.0-canary-388686f29-20230503.

Використання каналу canary для тестування інтеграції

Канал Canary також підтримує тестування інтеграції між React та іншими проектами.

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

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

• Налаштуйте завдання cron за допомогою бажаної платформи безперервної інтеграції. Завдання cron підтримуються як CircleCI, так і Travis CI.

• У завданні cron оновіть ваші пакети React до останнього випуску React на каналі Canary, використовуючи тег canary на npm. Використовуючи npm cli:

  npm update react@canary react-dom@canary

  або пряжа:

  yarn upgrade react@canary react-dom@canary

• Запустіть ваш набір тестів з оновленими пакунками.

• Якщо все пройшло, чудово! Ви можете очікувати, що ваш проект буде працювати з наступним молодшим релізом React.

• Якщо щось несподівано зламалося, будь ласка, повідомте нас про це за допомогою подання повідомлення про проблему.

Проектом, який використовує цей робочий процес, є Next.js. Ви можете звернутися до їхньої конфігурації CircleCI як до прикладу.

Експериментальний канал

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

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

Експериментальні випуски можуть суттєво відрізнятися від випусків до Canary та Latest. Не використовуйте експериментальні випуски у програмах, орієнтованих на користувача.Ви повинні очікувати частих змін між випусками в експериментальному каналі.

Випуски в експериментальному режимі публікуються з тегом experimental на npm. Версії генеруються з хешу вмісту збірки та дати фіксації, наприклад, 0.0.0-experimental-68053d940-20210623.

Що входить до експериментального релізу?

Експериментальні функції - це функції, які ще не готові до випуску для широкого загалу, і можуть суттєво змінитися до того, як їх буде завершено. Деякі експерименти може бути ніколи не завершено - причина, з якої ми проводимо експерименти, полягає у перевірці життєздатності запропонованих змін.

Наприклад, якби експериментальний канал існував, коли ми анонсували хуки, ми б випустили хуки для експериментального каналу за кілька тижнів до того, як вони стали б доступними в останньому.

Ви можете вважати корисним провести інтеграційні тести з експериментальним варіантом. Це залежить від вас. Однак зауважте, що Experimental ще менш стабільний, ніж Canary. Ми не гарантуємо стабільності між випусками Experimental.

Як дізнатися більше про експериментальні можливості?

Експериментальні можливості може бути як задокументовано, так і ні. Зазвичай, експерименти не документуються, доки вони не наближаються до відправлення у Canary або Latest.

Якщо функція не задокументована, вони можуть супроводжуватися RFC.

Коли ми будемо готові оголосити про нові експерименти, ми напишемо в Блозі React, але це не означає, що ми будемо публікувати кожен експеримент.

Ви завжди можете звернутися до нашого публічного репозиторію історії GitHub для отримання повного списку змін.