On 07/08/13 17:34, denis wrote:
>>
> а что делать тем, у кого в продакшене именно на 5.8 привязка? Переходить на
> центос 5, где эта версия прибита гвоздями и исключает какую-либо замену в
> принципе кроме насильственной компиляции поверх?
> У нас были проблемы с ухода с 5.8, и требовали переписывания примерно 20 своих
> модулей. Не полностью конечно, но работы было достаточно. Что мешало оставить
> эти версии не трогая, кроме ЧСВ?

Поддержка большого числа версий perl-а, требует дополнительных усилий от тех,
кто поддерживает порты perl-а и Mk/* (а поддержка нужна, потому что
инфраструктура портов развивается и иногда требует изменений в портах).

Поддерживать 5.10 который вышел в 2009-м и сейчас EoL желающих нет.

А вообще текущая стабильная версия perl-а уже 5.18.0 (но в портах пока нет).

Если у вас много perl-ового кода, который сложно изменить для работы с новыми
версиями perl, то проще сделать так:
1. nginx и весь остальной перловый софт разнести по разным jail-ам (или вирт.
машинам, если они есть).
2. В джайле с nginx использовать современный perl
В джайле с perl-овым софтом ставить нужный perl не из портов, а через
App::perlbrew, а модули ставить через Carton (и не обновлять, потому что рано
или поздно столкнетесь с тем, что модулю нужна более свежая версия перла, чем есть).

Я поддерживаю некоторый (не очень маленький) объем perl-ового кода и после 5.10
переход на последующие версии требовал простых изменений максимум нескольких
строчек кода (с конструкциями, давно объявленными устаревшими типа if
(defined(@array)) ). Из того, что я помню - сложным был только переход 5.6 -
5.8, когда сильно поменялась работа с unicode.
Ну и полезно иметь тесты. Возможность прогнать make test на новой версии перла
экономит время (хотя, конечно не гарантирует отсутствие багов)

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru