Практика регулярного выпуска обновлений ПО хорошо прижилась среди разработчиков свободного кода. Шести, четырех, трех месячные циклы выпуска релизов положительно сказываются на состоянии использующих их проектов. Они позволяют сконцентрироваться на конкретных краткосрочных задачах, быстрее исправлять недоработки и своевременно корректировать курс движения проекта. Вместе с тем, если назревает обширная перестройка структуры проекта и связанная с ним полная переработка кода (как, например, в случае с KDE4), то возникает опасность не уложиться в отведенные сроки. В таких случаях полезно было бы иметь в запасе более длительный промежуток времени на который планировать выпуск major-версий со значительными изменениями. Мета-цикл позволит стабилизировать произведенные изменения и подготовит основу для возвращения обратно на краткосрочные релизы.

Описав свое видение этой проблемы Шатлворт задается следующими вопросами:

• + Какая схема нумерации основных релизов должна применяться: X.0 как у KDE, или Y.X как у Python 2.6, или какая-то иная схема? И имеет ли нумерация, вообще, значение?
• + Как лучше осуществлять привязку мета-циклов: к годам (2-3 года) или к месяцам (18 или 30 месяцев)?
• + Какой продолжительности должны быть эти циклы: 1.5-2-2.5-3 года? На этот счет существуют две противоположные точки зрения: «железная» - связанная со скорейшим обновлением вычислительных компонентов и агитирующая за минимальную продолжительность цикла. Другая – «софтверная» - выступает за менее частую реинсталляцию ПО с «чистого листа» и длительность цикла в 3 года.
• + Как синхронизировать циклы различных проектов, зависящих друг от друга? Хотим ли мы иметь постепенное улучшение функциональности и стабильности, или основные релизы этих проектов должны случаться одновременно, внося неминуемый коллапс всей линейки зависимого ПО вначале, и далее нарастающую супер стабильность?
• + Есть ли удачные прецеденты работы по таким мета-циклам?

Добавить коментарий
Имя:
E-mail
Коментарий:
Код:*

Ваш коментарий будет первым