У матеріалі Ayesh Karunaratne розбирається перший Release Candidate PHP 8.4 і момент, коли гілка переходить у режим feature-freeze. Нижче — практичний конспект для тих, хто розробляє або супроводжує PHP-проєкти.
Що сталося: PHP 8.4 вийшов на етап RC1
Для PHP 8.4 вже доступний перший реліз-кандидат — PHP 8.4.0 RC1. З цього моменту гілка PHP 8.4 відділена від основної гілки розробки й більше не приймає нові можливості.
Feature-freeze означає, що:
- у гілку 8.4 більше не додають нові фічі або великі зміни;
- дозволені тільки виправлення багів та доопрацювання вже прийнятих можливостей;
- розробники екосистеми можуть спиратися на стабільний набір функцій для тестів.
Запланована дата General Availability (GA) для PHP 8.4.0 — 21 листопада 2024. До цього часу команда випустить ще кілька RC, щоб відловити й виправити критичні проблеми.
План релізів: RC2-RC4 та GA
За PHP 8.4.0 RC1 мають вийти ще три реліз-кандидати — RC2, RC3 та RC4. Кожен наступний RC — це крок до стабільного релізу з такими типами змін:
- усунення виявлених регресій (коли новий код ламає вже існуючу поведінку);
- виправлення крашів і критичних помилок безпеки;
- корекція документації й уточнення поведінки вже наявних фіч.
Після завершення цього циклу виходить перший GA-реліз — PHP 8.4.0. Саме його зазвичай розглядають як точку, з якої можна планувати поступове переведення продакшн-систем, якщо сумісність підтверджена тестами.
Новий цикл релізів і терміни підтримки PHP 8.4
Автор окремо підкреслює, що PHP 8.4 — перший реліз, який виходить уже за оновленою політикою реліз-циклу PHP. Для практики це означає чіткіші горизонти підтримки:
- 2 роки активної підтримки — у цей період виходять як виправлення багів, так і дрібні покращення в рамках мажорної версії;
- ще 2 роки тільки безпекових оновлень — виправляються вразливості, але нові фічі не додаються.
Для команд, які планують оновлення, це дає орієнтир: умовно, з дати GA у вас є 4 роки до повного End of Life, з яких перші 2 роки версію відносно комфортно тримати як основну.
Ключові нововведення PHP 8.4 (на рівні огляду)
У статті коротко згадано, які зміни вже закладені в PHP 8.4. Автор не розкладає їх детально, але виділяє кілька напрямів:
- Property Hooks — механізм, що додає нову поведінку до властивостей (наприклад, перехоплення читання або запису),
- Asymmetric visibility — розділення видимості для читання та запису властивостей, що допомагає будувати більш контрольовані API;
- Lazy Objects — підхід до відкладеного створення й ініціалізації об'єктів, корисний для великих доменних моделей і важких залежностей;
- Unicode 16 support — покращення підтримки Unicode, що важливо для роботи з рядками в багатомовних застосунках;
- різні поліпшення та депрікації, які потрібно перевіряти за офіційним списком змін для вашого коду й фреймворків.
За деталями щодо конкретних синтаксичних конструкцій і поведінки автор відсилає до окремої сторінки версії PHP 8.4.
Чи можна використовувати PHP 8.4 RC1 у продакшні
У статті прямо зазначено: PHP 8.4 на етапі RC1 ще не підходить для продакшн-систем. Це реліз для тестування, перевірки сумісності бібліотек, фреймворків і власних застосунків.
Типові сценарії, де RC1 уже має сенс:
- локальні середовища або окремі staging-сервера для тестів;
- CI-пайплайни з додатковою матрицею «PHP 8.4-rc»;
- експериментальні гілки фреймворків і бібліотек.
У продакшн-оточеннях розумніше чекати щонайменше GA-реліз і перші патч-релізи (8.4.1, 8.4.2), після чого планувати поступове оновлення з повним набором тестів.
Як спробувати PHP 8.4 RC1
Автор наводить кілька варіантів, як встановити й погратися з PHP 8.4 RC1 без прив'язки до продакшну.
Готові збірки для Windows
Для Windows уже опубліковані офіційні бінарні збірки PHP 8.4.0 RC1. Посилання й варіанти (Thread Safe, Non Thread Safe тощо) зібрані в розділі релізу:
Вони підходять для локальної розробки, експериментів на Windows-середовищах і перевірки CLI-скриптів.
Docker / OCI образи з тегом 8.4-rc
Для контейнеризованих середовищ уже доступні Docker/OCI-образи з тегом 8.4-rc на Docker Hub. У статті дається відсилання на розділ релізу з деталями:
Типовий практичний сценарій — додати до CI ще один job, який будує та ганяє тести вашого застосунку на образі PHP 8.4-rc поруч з поточною стабільною версією. Так можна рано помітити несумісності або нові депрікації.
Пакети для Linux (Ondrej / Remi)
Для більшості популярних дистрибутивів Linux збірками PHP традиційно займаються сторонні репозиторії. Автор згадує, що готові пакети PHP 8.4 RC1 вже є в сховищах Ondrej (для Ubuntu/Debian) та Remi (для Fedora/RHEL-подібних систем).
Конкретні команди встановлення залежать від дистрибутиву й не деталізуються в статті, але загальна ідея така:
- увімкнути відповідний сторонній репозиторій (Ondrej або Remi);
- поставити пакет PHP 8.4 поряд із наявною версією або в окремий префікс;
- не підмінювати системну версію PHP без необхідності — краще запускати RC окремо.
Збирання з вихідних кодів
Якщо потрібен повний контроль над конфігурацією PHP або хочете протестувати специфічні опції, можна зібрати PHP 8.4 з сорсів. Автор посилається на дві окремі інструкції:
- Compile PHP on Ubuntu/Debian-based distros — покроковий гайд для Debian/Ubuntu-подібних;
- Compile PHP on Fedora/RHEL-based systems — варіант для Fedora/RHEL/CentOS.
Ці матеріали описують типові етапи: встановлення збірних залежностей, конфігурацію з потрібними модулями, збірку й установку в окремий шлях, щоб не зламати системний PHP.
Практичні кроки для команд розробки
На основі інформації з статті можна сформувати мінімальний практичний план роботи з PHP 8.4 RC1:
- Додати PHP 8.4-rc до тестової матриці — через Docker-образи або окремий runner з RC1.
- Прогнати повний набір автотестів — особливо юніт-тести й інтеграційні сценарії з базами даних, чергами, кешем.
- Зібрати попередній список депрікацій — з офіційної сторінки PHP 8.4 і логів тестів.
- Перевірити ключові залежності — фреймворк, ORM, кеші, черги, основні пакети з Composer, які чутливі до версії PHP.
- Спланувати оновлення — орієнтуючись на дату GA (21.11.2024) і внутрішні реліз-цикли вашого продукту.
На цьому етапі головна користь від PHP 8.4 RC1 — можливість заздалегідь виявити несумісності й оцінити, які нові можливості можуть бути корисні для майбутніх версій вашого коду.
Джерело: Ayesh Karunaratne — PHP.Watch: новости