forked from extern/shorewall_code
9fd5780f36
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1439 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
152 lines
6.2 KiB
XML
152 lines
6.2 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
<article>
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>Shorewall Release Model</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate>2004-07-03</pubdate>
|
|
|
|
<copyright>
|
|
<year>2004</year>
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
</copyright>
|
|
|
|
<legalnotice>
|
|
<para>Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
1.2 or any later version published by the Free Software Foundation; with
|
|
no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
Texts. A copy of the license is included in the section entitled
|
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<section>
|
|
<title>Shorewall Releases</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Releases have a three-level identification
|
|
<firstterm>x.y.z</firstterm> (e.g., 2.0.3).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The first two levels (<emphasis>x.y</emphasis>) designate the
|
|
<firstterm>Major Release Number</firstterm> (e.g., 2.0).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The third level (<emphasis>z</emphasis>) designates the
|
|
<firstterm>Minor Release Number</firstterm>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Even numbered major releases (e.g., 1.4, 2.0, 2.2, ...) are
|
|
<firstterm>Stable Releases</firstterm>. No new features are added to
|
|
stable releases and new minor releases of a stable release will only
|
|
contain bug fixes. Installing a new minor release for the major
|
|
release that you are currently running involves no migration issues
|
|
(for example, if you are running 1.4.10 and I release 1.4.11, your
|
|
current configuration is 100% compatible with the new release).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Support is available through the <ulink
|
|
url="http://lists.shorewall.net">Mailing List</ulink> for the two most
|
|
recent Stable Releases.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Odd numbered major releases (e.g., 2.1, 2.3, ...) are
|
|
<firstterm>Development Releases</firstterm>. Development releases are
|
|
where new functionality is introduced. Documentation for new features
|
|
will be available but it may not be up to the standards of the stable
|
|
release documentation. Sites running Development Releases should be
|
|
prepared to play an active role in testing new features. Bug fixes and
|
|
problem resolution for the development release take a back seat to
|
|
support of the stable releases. Problem reports for the current
|
|
development release should be sent to the <ulink
|
|
url="mailto:shorewall-devel@lists.shorewall.net">Shorewall Development
|
|
Mailing List</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>When the level of functionality of the current development
|
|
release is judged adaquate, the <firstterm>Beta period</firstterm> for
|
|
a new Stable release will begin. Beta releases have identifications of
|
|
the form <emphasis>x.y.0-BetaN</emphasis> where <emphasis>x.y</emphasis>
|
|
is the number of the next Stable Release and <emphasis>N</emphasis>=1,2,3...
|
|
. Betas are expected to occur rougly once per year. Beta releases may
|
|
contain new functionality not present in the previous beta release
|
|
(e.g., 2.2.0-Beta4 may contain functionality not present in
|
|
2.2.0-Beta3). When I'm confident that the current Beta release is
|
|
stable, I will release the first <firstterm>Release Candidate</firstterm>.
|
|
Release candidates have identifications of the form
|
|
<emphasis>x.y.0-RCn</emphasis> where <emphasis>x.y</emphasis> is the
|
|
number of the next Stable Release and <emphasis>n</emphasis>=1,2,3...
|
|
. Release candidates contain no new functionailty -- they only contain
|
|
bug fixes. When the stability of the current release candidate is
|
|
judged to be sufficient then that release candidate will be released
|
|
as the new stable release (e.g., 2.2.0). At that time, the new stable
|
|
release and the prior stable release are those that are supported.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>What does it mean for a major release to be
|
|
<firstterm>supported</firstterm>? It means that I will answer
|
|
questions about the release and that if a bug is found, I will fix the
|
|
bug and include the fix in the next minor release.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Between minor releases, bug fixes will continue to be made
|
|
available through the <ulink url="errata.htm">Errata page</ulink> for
|
|
each major release.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>The currently-supported major releases are 1.4 and 2.0.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Old Release Model</title>
|
|
|
|
<para>This release model described above was adopted on 2003-07-03. Prior
|
|
to that time, a different release model was followed. Highlights of that
|
|
model were:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Releases were numbered in a manner similar to the current
|
|
release model.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>New functionality was added in minor releases of the current
|
|
major release. There was no concept of Stable vs Development major
|
|
releases.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Bug fix only releases were always against the last minor release
|
|
of a major release and had identifications of the form
|
|
<emphasis>x.y.zX</emphasis> (e.g., 2.0.3c) where <emphasis>X</emphasis>=1,b,c,...
|
|
. Consequently, if a user required a bug fix but was not running the
|
|
last minor release of the associated major release then it was
|
|
necessary to accept new functionailty along with the bug fix.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
</article> |