У матеріалі Ayesh Karunaratne розбирається рішення PHP Core team змінити цикл релізів PHP. Ці зміни напряму впливають на те, як часто командам доведеться оновлювати версії PHP у продакшені та як довго будуть виходити патчі безпеки.
Що саме змінилося в циклі релізів PHP
PHP Core team ухвалила RFC Release cycle update, який оновлює правила підтримки поточних і майбутніх релізів PHP. У RFC закладено кілька змін, але ключових для практики дві:
- збільшення періоду активної підтримки з 1 до 2 років для кожної мажорної версії PHP;
- продовження періоду тільки security-оновлень ще на 2 роки, тобто в сумі підтримка версії триває 4 роки;
- вирівнювання дат завершення активної підтримки і end-of-life під кінець календарного року — 31 грудня.
Раніше дата EOL для версії з security-only статусом наступала відразу після релізу наступної мажорної версії PHP. Тепер підтримка прив'язана не до виходу наступної версії, а до фіксованих календарних дат.
Як було раніше: 3 роки підтримки на версію
До змін кожна мажорна лінійка PHP (наприклад, PHP 8.3, 8.4, 8.5) мала такий життєвий цикл:
- 2 роки активних оновлень — багфікси + оновлення безпеки;
- 1 рік лише security-оновлень.
Фактично це давало 3 роки сумарної підтримки для кожної версії. Після закінчення цього періоду проєктам потрібно було або переходити на наступну активну версію PHP, або залишатися на EOL без офіційних патчів безпеки, покладаючись на власні міри захисту чи комерційну розширену підтримку.
Нова модель: 4 роки підтримки і чіткі календарні дати
Прийняте оновлення додає ще один рік security-патчів до кожної версії. За новою схемою:
- 2 роки активної підтримки — виправлення багів і вразливостей;
- 2 роки тільки security-оновлень — без нових фіч і несуттєвих багфіксів.
Таким чином, кожна мажорна версія PHP тепер отримує 4 роки офіційної підтримки замість 3. Це змінює горизонт планування для команд, які підтримують великі застосунки з довгим життєвим циклом: між міграціями з однієї підтримуваної версії на іншу стає трохи більше часу.
Друга важлива зміна — тепер як кінець активної підтримки, так і кінець security-періоду прив'язані до 31 грудня відповідних років. PHP-версія не переходить в EOL автоматично в день виходу наступного мажорного релізу, а «доживає» до кінця зазначеного року.
Як нові правила застосували до наявних версій
Зміни діють не лише для майбутніх гілок PHP, а й для вже активних на момент прийняття RFC. Ayesh Karunaratne наводить оновлену таблицю підтримки:
| PHP версія | Дата релізу | Активна підтримка до | Security-патчі до (EOL) |
|---|---|---|---|
| PHP 8.1 | 2021-11-25 | 2023-11-25 | 2025-12-31 |
| PHP 8.2 | 2022-12-08 | 2024-12-31 | 2026-12-31 |
| PHP 8.3 | 2023-11-23 | 2025-12-31 | 2027-12-31 |
| PHP 8.4 | 2024-11-21 | 2026-12-31 | 2028-12-31 |
| PHP 8.5 | 2025-11-20 (est) |
2027-12-31 | 2029-12-31 |
Ключові практичні наслідки з цієї таблиці
- PHP 8.1 вже не отримує активних оновлень (період завершився 2023-11-25), але продовжить отримувати security-патчі до 31.12.2025. Для застосунків на 8.1 це дає додатковий час, щоб спланувати перехід, але нові фічі чи звичайні багфікси вже не виходять.
- PHP 8.2 лишається в активній фазі до 31.12.2024, а потім іде у security-only до 31.12.2026. Це зручно як цільова версія для проєктів, що зараз мігрують з 8.0 або 8.1 і хочуть отримати максимально довгу підтримку без негайного переходу на 8.3+.
- PHP 8.3, 8.4 і планована 8.5 відразу стартують за новою моделлю: 2 роки активної підтримки плюс 2 роки security-періоду, з чіткими кінцевими датами на кінець календарного року.
Як адаптувати релізну політику проєкту до нового циклу
З погляду розробки й експлуатації, оновлення циклу релізів дає трохи більше маневру, але не скасовує регулярні міграції. Практичний підхід, який випливає з описаного в матеріалі:
- Планувати оновлення не рідше ніж раз на 2 роки. Активний період — це час, коли версія не лише безпечна, а й отримує багфікси. Затягування до останнього року security-only збільшує ризики залишитися з невиправленими нефатальними, але болючими багами.
- Прив'язувати дорожню карту до 31 грудня. Оскільки всі ключові дати тепер на кінець року, зручніше синхронізувати внутрішні релізи з цим графіком: наприклад, планувати міграцію на нову гілку PHP до початку останнього року security-підтримки поточної версії.
- Оцінювати «вік» стеку за таблицею підтримки. Для кожної продакшн-інсталяції варто окремо зафіксувати, на якій вона версії PHP, і співвіднести це з датами активного та security-періоду з таблиці вище, щоб зрозуміти запас часу до EOL.
- Уникати нового розгортання на версіях у кінці security-періоду. Наприклад, запускати новий продукт на версії, яка через рік входить в EOL, означає швидку обов'язкову міграцію.
Висновки для розробників і команд підтримки
За даними, які наводить Ayesh Karunaratne, після ухвалення RFC кожна мажорна версія PHP має 4 роки підтримки з чітко зафіксованими кінцевими датами, синхронізованими з календарним роком. Це зменшує невизначеність навколо моменту EOL і дає додатковий рік security-оновлень, але не скасовує потреби регулярно оновлюватися.
При плануванні життєвого циклу продукту тепер можна прямо спиратися на офіційні дати для 8.1, 8.2, 8.3 і майбутніх 8.4 та 8.5, зокрема на сторінках версій у PHP.Watch, які наведені в таблиці.
Джерело: Ayesh Karunaratne — PHP.Watch: новости