Чтобы решить какая версия FreeBSD больше всего подходит для ваших нужд, важно понимать несколько концепций, касающихся наших процессов разработки и подготовки релизов (Release Engineering, RE).

FreeBSD разрабатывается большой группой людей, являющихся почти полностью добровольцами. Исходный код ядра, самых распространённых библиотек и утилит поддерживается в системе контроля исходного кода (source control system) и доступен широкой публике для скачивания в любое время. Отдельно, скомпилированные версии (бинарники) доступны на рекуррентной основе. Некоторые из этих двоичных версий проходят широкое тестирование и затем обозначаются, как release.
1.1. Релизы

Имена Релизов строятся из старшего номера версии и младшего номера версии.

Цель старшего релиза - ввести новые возможности. Где необходимо, возможно нужно убрать совместимость с предыдущими старшими релизами, чтобы улучшить состояние FreeBSD, или, иногда убрать возможности, которые больше невозможно (или не нужно) поддерживать.

Цель младшего релиза - в основном исправление ошибок и улучшение производительности и стабильности. Поддержание совместимости между двумя младшими релизами приоритетно. Иногда новые возможности могут быть добавлены в младший релиз, когда видно, что другие цели не будут нарушены.

Тем не менее, помните, что релиз - это просто снэпшот дерева исходного кода в определённый момент времени, которому присваивается конкретное имя (тэг). (К примеру, тэг во время подготовки релиза присвоенный релизу 5.4 был RELENG_5_4_0_RELEASE). Разработка всегда продолжается в так называемом тэге HEAD.
1.2. Ветки

Во время каждого релиза создается ветка (к примеру, RELENG_5_4). Исходные файлы, названные RELENG_5_4_0_RELEASE изменяться никогда не будут, те которые в RELENG_5_4 изменяться могут путём принятия изменений из HEAD, таких как исправления в безопасности и другие ошибки.

Во время жизни каждого старшего релиза создаётся тэг (к примеру, RELENG_5). В дополнение к исправлениям в безопасности и исправлениям других ошибок, новые изменения могут быть приняты из HEAD, и таким образом составят изменения для следующего младшего релиза в последовательности.
1.3. STABLE против CURRENT

Во время жизни каждого старшего релиза, отдельная ветка может также называться STABLE. Это означает, что проект FreeBSD считает, что ветвь имеет достаточно доказанную стабильность для использования широким кругом пользователей. Ветви, которые нуждаются в дальнейшем тестировании перед тем, как стать в значительной степени принятой называются CURRENT.

Замечание: Проект FreeBSD ни внутри, ни вне себя не может гарантировать, что программное обеспечение, которое оно выпускает является достаточно стабильным для любой данной системы. Только каждый индивидуальный пользователь может сделать такое решение. Пожалуйста, помните, что Проект в основном состоит из добровольцев и не может предлагать любой вид гарантии пригодности.
1.4. Порты против Пакетов

Отдельно от файлов, распространяемых вышеуказанно, FreeBSD поддерживает тысячи приложений, которые разрабатываются третьими лицами, вне самого проекта. (Сюда включены оконные системы, интернет браузеры, почтовые программы, офисные пакеты, и так далее) В общем, сам проект не разрабатывает это программное обеспечение, только инфраструктуру, позволяющую установить эти программы (называется Коллекция портов). Приложения могут быть установлены либо из исходников, если условия лицензии позволяют такое распространение (они называются порты), либо в виде скомпилированных двоичных файлов, если разрешено (они называются пакеты).
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 иметь более лучший план на будущее.

Эти соображения более, чем любой вид погони за основным номером релиза любой другой ОС, включают основную мотивацию для продолжения изменений в планировании.
3. Улучшения целей планирования релизов

Вот текущие цели в планировании для Проекта:

Выпускать новый старший релиз каждые 18 месяцев;

Выпускать новый младший релиз каждые 4 месяца;

Обеспечивать предварительно собранные пакеты для последней младшей версии каждой старшей версии;

Обеспечивать предварительно собранные пакеты для последнего релиза каждой старшей версии;

Обеспечить обновления в безопасности и другие критические исправления ошибок для последних нескольких младших версий каждой старшей версии (ветки улучшений в безопасности, security branches).

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

Заинтересованные читатели также могут посмотреть текущее расписание подготовки релизов и расписание веток улучшений в безопасности. Оба документа содержат более детальную информацию по предпосылкам и разумные обоснования этих решений.
4. Как эти факторы повлияют на моё решение?

Основные факторы, которые могут повлиять на ваше решение в выборе версии для установки:

Какую степень стабильности требует ваша система?

Сколько усилий вы хотите прикладывать для обновлений?

Как долго вы планируйте оставаться на одной версии между обновлениями?

Как важна безопасность для вашей системы?

Будете ли вы устанавливаться из исходников или посредством двоичных файлов?

Желаете ли вы помочь участвовать в процессе разработки FreeBSD?

Вот некоторые примерные инструкции для помощи вам в вашем решении:

Если ваши нужды имеют краткосрочный характер, вы нуждаетесь в самой высокой степени стабильности, доступной на данный момент и не собираетесь обновлять большое количество ресурсов, то вы возможно захотите установить последний младший STABLE релиз и остаться с ним. В зависимости от ваших требований к безопасности, вы можете следить за изменениями в эту ветку, по мере их появления.

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

Если вы не планируете сразу промышленное использование, а хотите поработать с проблемами, и новый старший релиз появляется в следующие несколько месяцев, то вы можете поисследовать, установив эту ветку, чтобы помочь Проекту протестировать его, стабилизировать, сделать его самым лучшим релизом с уровнем качества выше среднего.

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