<!--
The FreeBSD Documentation Project
-->
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
<!ENTITY % freebsd.urls.absolute "INCLUDE">
<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//EN">
%articles.ent;
<!--
<!ENTITY art.re.pkgs '<ulink url="&url.articles.releng-packages;/article.html">The Release Engineering of Third Party Packages</ulink>'>
-->
]>
<article>
<title>Choosing the FreeBSD Version That Is Right For You</title>
<articleinfo>
<authorgroup>
<author>
<surname>The FreeBSD Documentation Project</surname>
</author>
</authorgroup>
<pubdate>$FreeBSD$</pubdate>
<legalnotice id="trademarks" role="trademarks">
&tm-attrib.freebsd;
</legalnotice>
<copyright>
<year>2005</year>
<holder>The FreeBSD Documentation Project</holder>
</copyright>
<abstract>
<para>So you have chosen to install &os;. Welcome! This
document is designed to help you to decide which version to
install.</para>
</abstract>
</articleinfo>
<sect1 id="background">
<title>Background</title>
<para>To decide which version of &os; is the best for your needs,
it is important to understand a few concepts about our development
and Release Engineering (<literal>RE</literal>) processes.</para>
<para>&os; is developed by a large group of individuals who are
almost entirely volunteers. The source code to the kernel and
the most common libraries and utilities is maintained in a
<firstterm>source control system</firstterm> and available for
the general public to download at any time. Separately, compiled
versions (<literal>binaries</literal>) are made available on a
recurring basis. Some of these binary versions undergo an
extensive testing process and are then termed a
<firstterm>release</firstterm>.</para>
<sect2 id="releases">
<title>Releases</title>
<para><literal>Releases</literal> are named with a <firstterm>major
version number</firstterm> and <firstterm>minor version
number</firstterm>.<para>
<itemizedlist>
<listitem>
<para>The goal of a major release is to introduce a set of new
features. Inevitably, as new features are added to &os;, or as
older features are no longer useful or are dropped, it is
sometimes necessary to break compatibility with previous major
releases.</para>
</listitem>
<listitem>
<para>The goal of a minor release is primarily to fix bugs and
improve performance and stability. Keeping both source-level and binary compatibility
from one minor release to another is a priority. On occasion,
new features may be added to a minor release when it is
believed that these other goals will not be compromised.</para>
</listitem>
</itemizedlist>
<para>However, keep in mind that a <quote>release version</quote>
is merely a snapshot of the source tree at a particular point in
time which is given a particular name (or <emphasis>tag</emphasis>).
(For instance, the tag that Release Engineering assigned for the
5.4 release was <literal>RELENG_5_4_0_RELEASE</literal>.) Development
always continues on what is known as the <literal>HEAD</literal>
tag.</para>
</sect2>
<sect2 id="branches">
<title>Branches</title>
<para>At the time of each release, a <firstterm>branch</firstterm>
is created, such as <literal>RELENG_5_4</literal>. Although
the source files named by <literal>RELENG_5_4_0_RELEASE</literal>
will never change, those on <literal>RELENG_5_4</literal> can,
by the adoption of changes from <literal>HEAD</literal> such
as fixes for security and other bugs.</para>
<para>During the life of each major release, another tag is
created such as <literal>RELENG_5</literal>. In addition
to security and other bug fixes, other new changes can be
brought in from <literal>HEAD</literal> so as to constitute
the changes for the next minor release in the sequence.</para>
</sect2>
<sect2 id="stable-vs-current">
<title><firstterm>STABLE</firstterm> versus
<firstterm>CURRENT</firstterm></title>
<para>During the lifetime of each major release, an individual
branch may also be termed <literal>STABLE</literal>. This
indicates that the &os; Project believes that the branch is
of sufficiently proven quality to be used by a wide range of
users. Branches that need further testing before being widely
adopted are named <literal>CURRENT</literal>.</para>
<note><para>The &os; Project cannot in and of itself guarantee
that the software that it ships is <emphasis>stable</emphasis>
enough for any given installation. Only each individual user
can make that decision. Please keep in mind that the Project
is primarily composed of volunteers and is not able to offer
any kind of warranty of fitness.</para></note>
</sect2>
<sect2 id="ports-vs-packages">
<title><firstterm>Ports</firstterm> versus
<firstterm>Packages</firstterm></title>
<para>Separately from the files distributed above, &os;
supports thousands of applications that are developed by third
parties outside of the project itself. (Examples include
windowing systems, Internet browsers, email programs, office
suites, and so forth.) In general, the project itself does
not develop this software, only the framework to allow these
programs to be installed (termed the <firstterm>Ports
Collection</firstterm>). Applications may be installed
either from source, if its licensing terms allow such
redistribution (these are called <emphasis>ports</emphasis>),
or as compiled binaries if allowed (these are called
<emphasis>packages</emphasis>).</para>
</sect2>
</sect1>
<sect1 id="past-schedules">
<title>Release Scheduling In The Past</title>
<para>During the development and release of &os; 5.X, many lessons
were learned which only became clear in retrospect. The goals
of the 5.X series were very aggressive, and included:</para>
<itemizedlist>
<listitem>
<para>To provide support for Symmetric MultiProcessing (SMP)
machines;</para>
</listitem>
<listitem>
<para>To increase performance by adopting a new strategy
for dealing with resource contention in the kernel;</para>
</listitem>
<listitem>
<para>To add several new processor architectures;</para>
</listitem>
<listitem>
<para>To introduce a new threading model;</para>
</listitem>
<listitem>
<para>To introduce a new scheduler;</para>
</listitem>
<listitem>
<para>To add support for new technologies such as power
management (especially important for laptops); and,
most critically,</para>
</listitem>
<listitem>
<para>Not to declare the release series as <literal>STABLE</literal>
until all these tasks were finished.</para>
</listitem>
</itemizedlist>
<para>This led to a situation where it was several years between
the time that a release in the 4.X series was declared
<literal>STABLE</literal> and that a release in the 5.X series
was declared <literal>STABLE</literal>. This had several
undesirable effects:</para>
<itemizedlist>
<listitem>
<para>The number of simultaneous feature-set changes made it
very difficult to isolate one set of changes for merging
back into the <literal>STABLE</literal> branch;</para>
</listitem>
<listitem>
<para>which meant that users who absolutely had to have certain
new features (for instance, to be able to run on modern hardware)
wound up adopting (for instance) &os; 5.2.1 even though it was
advertised as a developer-only release, and regardless of the
fact that a <literal>CURRENT</literal> release was not really
suitable for their needs.</para>
</listitem>
<listitem>
<para>In the cases where backmerges were made, this put the
developers in a position of trying to support features on a
version that they themselves were not using as their primary
development platform.</para>
</listitem>
<listitem>
<para>The time lag also meant that when 5.3 was finally declared
as the latest <literal>STABLE</literal> release, the accumulated
weight of changes made the upgrading process very painful.</para>
</listitem>
</itemizedlist>
<para>To put it bluntly, no one was satisfied with this result.</para>
<para>The lessons that were learned are:</para>
<itemizedlist>
<listitem>
<para>New major releases must have a smaller number of
feature-set changes and be released more often.</para>
</listitem>
<listitem>
<para>To the maximum extent possible, feature-set changes
should be isolated from each other. (This implies that
some development must take place outside of the main
tree and only be merged in when it will not destabilize
other simultaneous development.)</para>
</listitem>
<listitem>
<para>Major releases should be targeted at a time
deadline rather than a feature-set deadline. If some
feature is not ready in time, then it should be disabled
by default and left for the next major release.</para>
</listitem>
</itemizedlist>
<para>By releasing smaller sets of changes more often, it is
also hoped that less time will be spent trying to merge features
from <literal>HEAD</literal> back into the latest
<literal>STABLE</literal> version (and thus trying to support
those features in more than one major version); and further, that
as the changes are more isolated, that the risk of introducing
more bugs by doing so is much less.</para>
<para>Also, by focusing on a time deadline rather than a
feature set, it should finally be possible for users, developers
of external applications, and the &os; developers themselves to
be able to better plan for the future.</para>
</sect1>
<sect1 id="future-goals">
<title>Release Scheduling Goals Going Forward</title>
<para>Here are the current scheduling goals for the Project:</para>
<itemizedlist>
<listitem>
<para>To release a new major release every 18 months;</para>
</listitem>
<listitem>
<para>To release a new minor release every 4 months;</para>
</listitem>
<listitem>
<para>To provide prebuilt packages for the most recent minor
release of each major version;</para>
</listitem>
<listitem>
<para>To provide security updates and other critical bug fixes
for the last several minor versions of each major version
(termed <firstterm>security branches</firstterm>).</para>
</listitem>
</itemizedlist>
<para>Due to the large number of possible combinations of installable
versions, it is not possible to support every version
indefinitely; this is due somewhat to the availability of machine
resources but primarily due to the amount of volunteer effort
that is available.</para>
<para>Interested readers should also see:</para>
<variablelist>
<varlistentry>
<term><ulink url="&url.base;/releng/index.html#schedule"></ulink></term>
<listitem>
<para>The Release Engineering Schedule</para>
</listitem>
</varlistentry>
<varlistentry>
<term><ulink url="&url.base;/security/security.html#supported-branches"></ulink></term>
<listitem>
<para>The Security Branch Schedule</para>
</listitem>
</varlistentry>
</variablelist>
<para>These documents go into much greater depth about the background and
rationale behind the decisions regarding the supported branches and the
lifetime of each branch.</para>
</sect1>
<sect1 id="decision-points">
<title>How Do These Factors Affect My Decision?</title>
<para>The major factors that should affect your decision as to
which version to install include:</para>
<itemizedlist>
<listitem>
<para>What degree of stability does your installation need?</para>
</listitem>
<listitem>
<para>How much effort do you wish to devote to upgrading?</para>
</listitem>
<listitem>
<para>How long do you intend to stay on a particular version
between upgrades?</para>
</listitem>
<listitem>
<para>How important is security to your installation?</para>
</listitem>
<listitem>
<para>Will you be installing from source, or from binaries?<para>
</listitem>
<listitem>
<para>Are you willing to help participate in the &os; development
process?</para>
</listitem>
</itemizedlist>
<para>Here are some rough guidelines to help you in your decision:</para>
<itemizedlist>
<listitem>
<para>If you have a short-term need, would benefit from the highest degree of
stability currently available, and are not able to devote many
resources to upgrading, then you will probably want to install
the latest <literal>STABLE</literal> minor release and remain
with that. Depending on your security needs, you may or may not
wish to track changes to that branch as they are released.</para>
</listitem>
<listitem>
<para>If you have a short-term need, and feature completeness or
the best levels of security are most important to you, and you
are willing to spend time upgrading, you may wish to track the
latest <literal>STABLE</literal> branch.</para>
</listitem>
<listitem>
<para>If you are not immediately planning on going into
production, you are willing to work through a certain number
of problems, and a new major release is upcoming within the
next few months, you may wish to investigate installing that
branch to help the project to test it and stabilize it
to make it the best release possible in the medium to long
term.</para>
</listitem>
<listitem>
<para>Only if you are willing to install from source, and spend
time debugging problems with the base system and follow up
with problem reports, and track the mailing list that deals
with such issues, should you consider tracking
<literal>HEAD</literal>.</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="conclusion">
<title>Conclusion</title>
<para>We hope that this article serves as a useful starting point
for understanding the &os; development model and deciding what version
is right for your needs.</para>
</sect1>
</article>