os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add a new article, "How To Choose The Version Of FreeBSD That Is

Browse source 
Right For You."

This article attempts to provide an introduction to such concepts
as Releases, Branches, and STABLE vs. CURRENT, which are currently
scattered around between the FAQ, various Release Engineering documents,
and folklore on the mailing lists.

The material in the FAQ should probably be deleted and this used as
its replacement.  This material does not replace any of the Release
Engineering documentation, but it does attempt to discuss how the
concepts discussed in great detail therein should influence user
decisions on which version to install.  In particular, this article
attempts to inform users about the current thinking of the development
team in terms of how future releases are going to be done.

A companion article comparing e.g. 5.X vs 6.X would be useful but is
outside the scope of this commit.

This article is partially a response to the "Quality of FreeBSD" thread
on freebsd-stable in July 2005 (and its many antecedents).

Submitted for review to:	core, re, secteam
Reviewed by:			imp, wes, remko, simon, and others
This commit is contained in:
Mark Linimon 2005-08-17 07:18:50 +00:00
parent bb1c86620d
commit e01b784ea1
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=25389
3 changed files with 417 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
en_US.ISO8859-1/articles/Makefile
View file

@ -39,6 +39,7 @@ SUBDIR+= releng-packages
SUBDIR+= serial-uart
SUBDIR+= solid-state
SUBDIR+= storage-devices
SUBDIR+= version-guide
SUBDIR+= vinum
SUBDIR+= vm-design
SUBDIR+= zip-drive

21
en_US.ISO8859-1/articles/version-guide/Makefile Normal file
View file

@ -0,0 +1,21 @@
#
# $FreeBSD$
#
# Article: FreeBSD Version Guide
DOC?= article
FORMATS?= html
WITH_ARTICLE_TOC?= YES
INSTALL_COMPRESSED?= gz
INSTALL_ONLY_COMPRESSED?=
SRCS= article.sgml
CSS_SHEET_ADDITIONS= extra.css
URL_RELPREFIX?= ../../../..
DOC_PREFIX?= ${.CURDIR}/../../..
.include "${DOC_PREFIX}/share/mk/doc.project.mk"

395
en_US.ISO8859-1/articles/version-guide/article.sgml Normal file
View file

@ -0,0 +1,395 @@
<!--
The FreeBSD Documentation Project
-->
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
<!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 &os; Documentation Project</surname>
</author>
</authorgroup>
<pubdate>$FreeBSD$</pubdate>
<legalnotice id="trademarks" role="trademarks">
&tm-attrib.freebsd;
</legalnotice>
<copyright>
<year>2005</year>
<holder>The &os; 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's 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>
<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. Where necessary, it may be necessary to break
compatibility with previous major releases in order to advance
the state of &os;, or, occasionally, to drop features that
it is no longer feasible to support.</para>
</listitem>
<listitem>
<para>The goal of a minor release is primarily to fix bugs and
improve performance and stability. Keeping 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 <literal>release version</literal>
is merely a snapshot of the source tree at a particular point in
time which is given a particular name (or <literal>tag</literal>).
(For instance, the tag that Release Engineering assigned for the
5.4 release was <literal>RELENG_5_4_RELEASE</literal>.) Development
always continues on what is known as the <literal>HEAD</literal>
tag.</para>
</sect2>
<sect2>
<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_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 bugfixes, 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>
<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>
<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 termed <literal>ports</literal>,
or as compiled binaries if allowed (these are termed
<literal>packages</literal>).</para>
</sect2>
</sect1>
<sect1>
<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
undesireable 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, is the main motivation for
the scheduling changes going forward.</para>
</sect1>
<sect1>
<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
version of each major version;</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 bugfixes
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 the current
<ulink url="&url.base;/releng/index.html#schedule">Release
Engineering Schedule</ulink> and
<ulink url="&url.base;/security/security.html#adv">Security
Branch Schedule</ulink>. Both documents also go into much
greater depth about the background and rationale behind
these decisions.</para>
</sect1>
<sect1>
<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, need 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>
<title>Conclusion</title>
<para>We hope that this article serves as a useful starting point
for understand the &os; development model and deciding what version
is right for your needs.</para>
</sect1>
</article>