PHP отказывается от PEAR: RFC принят единогласно (40–0)
Голосование по RFC «End PEAR Project Endorsement» закрылось 19 октября 2026 года. PEAR перестаёт быть официально одобренным способом установки PHP-пакетов, сайт pear.php.net превращается в статический архив, а php.net указывает на Composer.
19 октября 2026 года в 13:15 UTC закрылось голосование по RFC «End PEAR Project Endorsement» — предложению официально прекратить одобрение проекта PEAR со стороны PHP. Итог, подтверждённый в треде голосования в рассылке php.internals: 40 голосов «за», 0 «против», при требуемом пороге в две трети. Решение принято без единого голоса против.
Что решили
RFC обсуждался с 27 августа и выносился на голосование 5 октября. Авторы предложения указали на формальную причину: из 603 пакетов в репозитории PEAR 534 помечены как unmaintained, а сам установщик PEAR давно не отражает реальную практику установки зависимостей в PHP-экосистеме, где de facto стандартом стал Composer.
Вместо резкого отключения RFC предусматривает управляемый переход в четыре шага: PHP прекращает официальное одобрение PEAR как способа установки пакетов; дистрибутивы исходников PHP перестают включать установщик PEAR; текущий сайт pear.php.net становится статическим архивом страниц пакетов, загрузок, мануалов и публичных багтрекеров; почтовые списки рассылки PEAR переводятся в неактивный раздел.
Что конкретно меняется
| Когда | Что происходит |
|---|---|
| PHP 8.7 | Исходники PHP больше не включают установщик PEAR |
| До 31 декабря 2027 | Статический архив pear.php.net доступен для просмотра, CLI-эндпоинты PEAR продолжают работать для старых инсталляций |
| После 31 декабря 2027 | Архив остаётся доступен только как файл для скачивания |
Для разработчиков, которые годами не трогали PEAR, фактически ничего не меняется — Composer уже был стандартом де-факто. А вот для legacy-проектов, которые всё ещё используют pear install на деплое, это сигнал закрыть этот технический долг до выхода 8.7: архив сохранит работоспособность CLI до конца 2027 года, но не дольше.
Почему именно сейчас
PEAR появился в 1999 году и долгое время был единственным официальным способом распространять переиспользуемый PHP-код. Composer, запущенный в 2011 году и ориентированный на Packagist, решил те же задачи проще: констрейнты версий в composer.json, детерминированная установка через composer.lock и встроенный аудит уязвимостей, о котором мы писали в разборе практик работы с Composer.
К 2026 году разрыв в активности стал слишком заметным, чтобы официальное одобрение PEAR оставалось честным: почти девять из десяти пакетов репозитория не поддерживаются, а новая документация и материалы для новичков годами ссылались на Composer, а не на PEAR. Формальное голосование лишь закрепило то, что на практике произошло уже давно.
Что это значит для вашего проекта
- Если проект уже использует Composer — изменений в рабочем процессе нет, менять ничего не нужно
- Если в CI или на продакшене ещё остался шаг с
pear install— стоит запланировать миграцию на Composer-эквивалент пакета до выхода PHP 8.7 - Ссылки на pear.php.net в старой документации продолжат работать как минимум до конца 2027 года, но полагаться на них в новых материалах уже не стоит
- Собственные форки или внутренние пакеты, которые раньше публиковались через PEAR-канал, нужно перенести на Packagist или приватный Composer-репозиторий
Итог для большинства команд спокойный: PHP не ломает совместимость резко, а формально закрывает главу, которая на практике была закрыта уже несколько лет назад.
