diff --git a/en_US.ISO8859-1/articles/Makefile b/en_US.ISO8859-1/articles/Makefile index c62672e95b..d24dbaba75 100644 --- a/en_US.ISO8859-1/articles/Makefile +++ b/en_US.ISO8859-1/articles/Makefile @@ -1,49 +1,50 @@ # $FreeBSD$ SUBDIR = SUBDIR+= 5-roadmap SUBDIR+= checkpoint SUBDIR+= committers-guide SUBDIR+= console-server SUBDIR+= contributing SUBDIR+= contributors SUBDIR+= cvs-freebsd SUBDIR+= cvsup-advanced SUBDIR+= dialup-firewall SUBDIR+= diskless-x SUBDIR+= euro SUBDIR+= explaining-bsd SUBDIR+= fbsd-from-scratch SUBDIR+= filtering-bridges SUBDIR+= fonts SUBDIR+= formatting-media SUBDIR+= freebsd-questions SUBDIR+= hats SUBDIR+= hubs SUBDIR+= ipsec-must SUBDIR+= java-tomcat SUBDIR+= laptop SUBDIR+= linux-comparison SUBDIR+= mailing-list-faq SUBDIR+= mh SUBDIR+= multi-os SUBDIR+= new-users SUBDIR+= pam SUBDIR+= portbuild SUBDIR+= pr-guidelines SUBDIR+= problem-reports SUBDIR+= pxe SUBDIR+= relaydelay SUBDIR+= releng SUBDIR+= releng-packages SUBDIR+= serial-uart SUBDIR+= solid-state SUBDIR+= storage-devices +SUBDIR+= version-guide SUBDIR+= vinum SUBDIR+= vm-design SUBDIR+= zip-drive # ROOT_SYMLINKS+= new-users DOC_PREFIX?= ${.CURDIR}/../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/en_US.ISO8859-1/articles/version-guide/Makefile b/en_US.ISO8859-1/articles/version-guide/Makefile new file mode 100644 index 0000000000..553b5903be --- /dev/null +++ b/en_US.ISO8859-1/articles/version-guide/Makefile @@ -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" diff --git a/en_US.ISO8859-1/articles/version-guide/article.sgml b/en_US.ISO8859-1/articles/version-guide/article.sgml new file mode 100644 index 0000000000..d8e661928c --- /dev/null +++ b/en_US.ISO8859-1/articles/version-guide/article.sgml @@ -0,0 +1,395 @@ + + + +%articles.ent; + +]> + +
+ Choosing the FreeBSD Version That Is Right For You + + + + + The &os; Documentation Project + + + + $FreeBSD$ + + + &tm-attrib.freebsd; + + + + 2005 + The &os; Documentation Project + + + + So you have chosen to install &os;. Welcome! This + document is designed to help you to decide which version to + install. + + + + + Background + + 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 (RE) processes. + + &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 + source control system and available for + the general public to download at any time. Separately, compiled + versions (binaries) are made available on a + recurring basis. Some of these binary versions undergo an + extensive testing process and are then termed a + release. + + + Releases + + releases are named with a major + version number and minor version + number. + + + + 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. + + + + 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. + + + + However, keep in mind that a release version + is merely a snapshot of the source tree at a particular point in + time which is given a particular name (or tag). + (For instance, the tag that Release Engineering assigned for the + 5.4 release was RELENG_5_4_RELEASE.) Development + always continues on what is known as the HEAD + tag. + + + + Branches + + At the time of each release, a branch + is created, such as RELENG_5_4. Although + the source files named by RELENG_5_4_RELEASE + will never change, those on RELENG_5_4 can, + by the adoption of changes from HEAD such + as fixes for security and other bugs. + + During the life of each major release, another tag is + created such as RELENG_5. In addition + to security and other bugfixes, other new changes can be + brought in from HEAD so as to constitute + the changes for the next minor release in the sequence. + + + + <firstterm>STABLE</firstterm> versus + <firstterm>CURRENT</firstterm> + + During the lifetime of each major release, an individual + branch may also be termed STABLE. 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 CURRENT. + + The &os; Project cannot in and of itself guarantee + that the software that it ships is stable + 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. + + + + <firstterm>ports</firstterm> versus + <firstterm>PACKAGES</firstterm> + + 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 Ports + Collection). Applications may be installed + either from source, if its licensing terms allow such + redistribution (these are termed ports, + or as compiled binaries if allowed (these are termed + packages). + + + + + Release Scheduling In The Past + + 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: + + + + To provide support for Symmetric MultiProcessing (SMP) + machines; + + + + To increase performance by adopting a new strategy + for dealing with resource contention in the kernel; + + + + To add several new processor architectures; + + + + To introduce a new threading model; + + + + To introduce a new scheduler; + + + + To add support for new technologies such as power + management (especially important for laptops); and, + most critically, + + + + Not to declare the release series as STABLE + until all these tasks were finished. + + + + This led to a situation where it was several years between + the time that a release in the 4.X series was declared + STABLE and that a release in the 5.X series + was declared STABLE. This had several + undesireable effects: + + + + The number of simultaneous feature-set changes made it + very difficult to isolate one set of changes for merging + back into the STABLE branch; + + + + 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 CURRENT release was not really + suitable for their needs. + + + + 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. + + + + The time lag also meant that when 5.3 was finally declared + as the latest STABLE release, the accumulated + weight of changes made the upgrading process very painful. + + + + To put it bluntly, no one was satisfied with this result. + + The lessons that were learned are: + + + + New major releases must have a smaller number of + feature-set changes and be released more often. + + + + 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.) + + + + 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. + + + + By releasing smaller sets of changes more often, it is + also hoped that less time will be spent trying to merge features + from HEAD back into the latest + STABLE 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. + + 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. + + 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. + + + + Release Scheduling Goals Going Forward + + Here are the current scheduling goals for the Project: + + + + To release a new major release every 18 months; + + + + To release a new minor release every 4 months; + + + + To provide prebuilt packages for the most recent minor + version of each major version; + + + + To provide prebuilt packages for the most recent minor + release of each major version; + + + + To provide security updates and other critical bugfixes + for the last several minor versions of each major version + (termed security branches). + + + + 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. + + Interested readers should also see the current + Release + Engineering Schedule and + Security + Branch Schedule. Both documents also go into much + greater depth about the background and rationale behind + these decisions. + + + + How Do These Factors Affect My Decision? + + The major factors that should affect your decision as to + which version to install include: + + + + What degree of stability does your installation need? + + + + How much effort do you wish to devote to upgrading? + + + + How long do you intend to stay on a particular version + between upgrades? + + + + How important is security to your installation? + + + + Will you be installing from source, or from binaries? + + + + Are you willing to help participate in the &os; development + process? + + + + Here are some rough guidelines to help you in your decision: + + + + 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 STABLE 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. + + + + 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 STABLE branch. + + + + 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. + + + + 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 + HEAD. + + + + + + Conclusion + + 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. + +