2. Планирование релизов в прошлом

Во время разработки и выпуска FreeBSD 5.X было получено много уроков, которые стали ясны только ретроспективно. Цели серии 5.X были очень мощными и включали:

• Обеспечить поддержку машин с симметричной мультипроцессорностью (Symmetric MultiProcessing, SMP);

• Увеличить производительность, путём применения новой стратегии работы с конкуренцией ресурсов в ядре;

• Добавить несколько новых архитектур процессоров;

• Ввести новую модель тредов;

• Ввести новый планировщик;

• Добавить поддержку новых технологий, таких как управление питанием (это особенно важно для лэптопов); и наиболее критично,

• Не объявлять серии релизов, как STABLE до тех пор, пока все эти задачи не будут выполнены.

Это привело к ситуации, когда между моментом временем, когда релиз из серии 4.X был объявлен, как STABLE и моментом, когда релиз из 5.X был объявлен, как STABLE прошло несколько лет. Это имело несколько нежелательных эффектов:

• Количество одновременных изменений групп характеристик сделало очень сложным изолирование одного набора изменений для слияния обратно в STABLE ветку;

• что означало, что пользователи, которые должны иметь определённые новые возможности (к примеру, использовать современное оборудование) работали путём адаптирования (к примеру) FreeBSD 5.2.1 хотя он был известен, как релиз только для разработчиков, и независимо от того факта, что CURRENT релиз не совсем подходил для их нужд.

• В случаях, когда обратные слияния имели место, это поставило разработчиков в положение, когда они пытались поддерживать характеристики (feautures) на версии, которую они сами не использовали, как первичную платформу для разработки.

• Задержка во времени также значила, что когда 5.3 был наконец объявлен самым последним STABLE релизом, накопившееся количество изменений сделало процесс обновления очень болезненным.

Более кратко, никто не был доволен результатом.

Уроки, которые были получены:

• Новые старшие релизы должны иметь меньшее количество серьезных изменений характеристик и выпускаться более часто.

• В самой большой степени, серьезные изменения должны изолироваться друг от друга. (Это подразумевает, что некоторая разработка должна вестись вне основного дерева и может быть объединена с основным деревом только при условии, что это не нарушит другую одновременно продолжающуюся разработку.)

• Старшие релизы должны ориентироваться на последний срок по времени, а не на последний срок по количеству характеристик. Если какая-то возможность (характеристика) не закончена вовремя, то она должна быть убрана и оставлена до следующего старшего релиза.

С помощью более частого выпуска меньшего количества изменений, также существует надежда, что меньше времени будет проводиться, пытаясь заниматься слиянием характеристик из HEAD обратно в последнюю STABLE версию (и тем самым пытаясь поддерживать эти характеристики более, чем в одной старшей версии); и далее, чем изменения более изолированы, тем риск появления новых ошибок намного меньше.

Также, фокусируясь больше на последний срок по времени нежели по количеству характеристик, в итоге будет возможным для пользователей, разработчиков внешних приложений и самих разработчиков FreeBSD иметь более лучший план на будущее.