PHP 5.2.0 и политика релизов PHP
Вышел PHP 5.2.0. Разработчики заявляют, что проведена большая работа по оптимизации скорости, потреблению памяти, исправлены серьёзные ошибки (например, переполнение буфера в htmlspecialchars() и htmlentities()).
С выходом данной версии ветка 5.1.x объявляется устаревшей, рекомендуется перейти на 5.2 как можно скорее. Другими словами, 5.1.х больше не поддерживается.
На мой взгляд, разработчики PHP очередной раз продемонстрировали пример очень непродуманного подхода к выпуску новых версий. Выходит так, что для того, чтобы “закрыть” уязвимости, все должны срочно обновляться до 5.2. Но ведь эта версия не только исправляет и улучшает, но и добавлят и расширяет. Любому начинающему программисту известно, что, когда разрабатывается что-то новенькое, почти всегда возникают проблемы, у кого-то что-то не работает, где-то появляются ошибки – другими словами, от новой функциональности всегда стоит ожидать непредвиденных сложностей и проблем. Даже если это незначительные добавления и изменения.
Кстати, с 5.1.0 было так же – с выходом этой версии 5.0.x была объявлена “вне закона”. Такое впечатление, что они не используют “ветки” (“branches”) CVS.
Не первый раз я недоумеваю по поводу политики релизов PHP. Например, версия 5.1.1 была выпущена cпустя всего несколько дней после выхода 5.1.0 – разработчикам пришлось откатывать некоторые нововведения версии 5.1.0, причём основная причина проблемы была в недопонимании внутри команды (см. разъяснения Ильи Альшанетского по этому поводу). С 5.1.4 было нечто подобное (плохо отестировали 5.1.3?)...
Не понимаю, как Zend&Co планируют завоёвывать “enterprise”-рынок. По моему, им стоит поучиться более серьёзному и обдуманному подходу в планировании релизов. Например, у PostgreSQL. Поучиться таким вещам, как feature freeze time (когда существует чёткое разделение между новой функциональностью и ошибками), плавный отказ от текущих веток (когда в используемые большинством ветки помещаются только исправления серьёзных ошибок, что позволяет латать дыры, не создавая новых), build farm (когда новая версия тестируется достаточно долго на достаточно большом количестве различных систем до релиза, а не после) и т.п. Хотя, может быть, PHP этого не нужно? Может и без этого enterprise ждёт его с распростёртыми объятьями?
