Проект KDE рассматривает возможность перехода на трёхмесячный цикл подготовки значительных выпусков
Разработчики проекта KDE рассматривают вопрос о сокращении цикла подготовки значительных выпусков. В соответствии с опубликованным предложением, релизы планируется формировать раз в три месяца, что позволит ускорить доведение новых возможностей до пользователей и упростить формирование выпуска за счёт сокращения числа изменений и введения единой заморозки для всех компонентов KDE. По мнению авторов предложения ускорить темп разработки можно за счёт сокращения фазы тестирования — для обеспечения стабильности предлагается поддерживать master-ветку в постоянно стабилизированном и готовом к релизу виде. Два месяца предлагается уделить приёму новых возможностей, а третий месяц потратить на формирование релиза и бета-тестирование. Таким образом, значительные выпуски будут выходить чаще и включить только возможности, готовые для использования в текущий момент. Предложение будет рассмотрено на ближайшем саммите разработчиков и в случае одобрения будет применено в процессе подготовки KDE SC 4.12.
Против предложения уже выступили представители проекта openSUSE, которые указали на том, что для поддержания пакетов с KDE в дистрибутиве оптимальным является текущий шестимесячный цикл разработки. При более частом формировании релизов нагрузка на мэйнтейнеров пакетов заметно возрастёт, что может отрицательно сказаться на качестве интеграции KDE в дистрибутив. Кроме того, значительные релизы раз в три месяца плохо синхронизируются с типичным 6- и 8-месячными циклами подготовки дистрибутивов.
В противовес авторы инициативы указывают на то, что релизы будут содержать меньше изменений и соответственно меньше ошибок, что скажется на упрощении процесса тестирования. Дистрибутивы также смогут включать в свой состав более свежие версии KDE, так как можно будет избежать ситуации когда очередной значительный выпуск KDE выходит после заморозки пакетной базы и дистрибутив вынужден поставлять устаревшее окружение, так как не успевает интегрировать новую версию.
© OpenNet