40ff5e8d3d
problem. The proper solution is to use the freebsd.urls.absolute parameter entity, let's use it from now on. Pointed out by: pgj
405 lines
14 KiB
Text
405 lines
14 KiB
Text
<!--
|
|
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 be finally be possible for users, developers
|
|
of external applications, and the &os; developers themselves to
|
|
be able to better plan for the future.</para>
|
|
|
|
<para>These considerations, rather than any kind of keeping up with
|
|
the major release number of any other OS, comprise the main motivation for
|
|
the scheduling changes going forward.</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>
|