Похоже Марк всё же внемлил жалобам на зоопарк версий и неудобство менять дист каждые пол года:
Марк считает 6-ти месячные релиз-циклы великолепной идеей, но поднимает в своей статье вопросы по поводу более длительных циклах разработки (в 2-3 года), которые необходимы для предоставления продолжительной и качественной поддержки выпускаемых продуктов.
читать дальшеМарк Шатлворт:
Практика регулярных релизов становится широко распространенной (kernel, GNOME и KDE, X, дистрибутивы: Ubuntu, Fedora). Идея регулярных и предсказуемых релиз-циклов получила признание. Но необходимо признавать недостатки:
сложно сообщить пользователям о существенных изменениях
трудность поддержки, т.к не возможно поддерживать каждый релиз продолжительное время
Основные дистрибутивы, как правило, имеют "большой" релиз, а между ними более частые релизы. RHEL -> Fedora, Ubuntu LTS -> Ubuntu, Debian придерживается похожей стратегии, но не выпускает промежуточных версий.
С выходом 8.04 LTS, мы говорили , что было бы неплохо сказать заранее, когда выйдет следующий LTS дистрибутив. Я считал, что это будет 10.04 LTS(основной 2-х летний цикл). Но тогда не будет возможности координироваться с основными релизами других крупных дистрибутивов - Debian, Suse или Red Hat.
В беседах со Стивом Макинтайером (нынешний лидер проекта Debian), мы выявили интересные возможности для сотрудничества. Debian стремится к 18-месячному циклу, в котором их следующий релиз выйдет где-то в октябре 2010 года. Примерно в то же время выйдет релиз Ubuntu 10.10. Мы могли бы отложить Ubuntu LTS до 10.10. Это позволит сделать обмен патчами много проще. На конференции в Барселоне в мае у нас будут хорошие возможности изучить эту возможность в деталях.
Я говорил также с людьми из Novell, но они не разделяют мое точку зрения на данный момент.
И так, основные вопросы, которые интересуют меня:
Какие вещи должны быть рассмотрены при планировании мета-циклов? Какие проблемы они вызывают и каким образом лучше всего их решать? Какие короткие циклы (3 месяца, 6 месяцев) лучше вписываются в более длительный мета-цикл? Подходит ли название мета-цикл к описанию длительных циклов?
Стоит ли "первый релиз из основного цикла" (KDE 4.0, Python 3.0) делать как короткий цикл, который не получит долгосрочной поддержки?
Какой релиз из "длительных циклов" лучше всего подходит для долгосрочной поддержки? Это последний из релизов, до начала новых крупных изменений (Python 2.6; GNOME 2.28)? Или же релиз, следующий после выхода новой ветки разработки (KDE 4.2; GNOME 3.2)? Это важно, потому что крупные организации хотят более длительной поддержки?
Каков должен быть основной цикл разработки? Я придерживаюсь мнения - 2 года. Но в неформальных разговорах об этом, некоторые люди говорили о 18 месяцах, а другие заявляли о 30 месяцах (2,5 лет). Я думаю, они сумашедшие, что вы думаете?
Стоит ли проектам, связанным с аппаратной частью, иметь собственный цикл разработки, отличающийся от более высокоуровневых проектов?
Что делать с такими проектами как GCC, X, OpenOffice?
Пожалуйста, напишите что вы думаете обо всем этом. Я уверен, что вместе мы сможем выйти на совершенно новый уровень разработки, если сможем договориться о новой модели выхода релизов.
@темы:
Ubuntu,
Мысли вслух