mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-26 17:43:15 +01:00
4a10f31d7f
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@8609 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
173 lines
7.0 KiB
XML
173 lines
7.0 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<article>
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>Shorewall Release Model</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2004</year>
|
|
|
|
<year>2005</year>
|
|
|
|
<year>2006</year>
|
|
|
|
<year>2007</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 id="Releases">
|
|
<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 major new features are
|
|
added to stable releases and new minor releases of a stable release
|
|
will only contain bug fixes and simple low-risk enhancements.
|
|
Installing a new minor release for the major release that you are
|
|
currently running involves no migration issues unless you want to take
|
|
advantage of an enhancement (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://sourceforge.net/mail/?group_id=22587">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>
|
|
|
|
<listitem>
|
|
<para>Additionally, bug fixes may be made available in the form of a
|
|
<firstterm>patch release</firstterm>. Patch releases have four-level
|
|
identifications (e.g., 4.0.6.1); the first three identify the minor
|
|
release and the fourth identifies the patch level.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>We are currently waiving the two major release rule and are
|
|
supporting three major releases — the currently-supported major releases
|
|
are 3.2.x, 3.4.x and 4.0.x.</para>
|
|
</section>
|
|
|
|
<section id="Old">
|
|
<title>Old Release Model</title>
|
|
|
|
<para>This release model described above was adopted on 2004-07-03 and
|
|
modified 2004-07-21. Prior to 2004-07-03, 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>Major 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 might be necessary to accept major new
|
|
functionailty along with the bug fix.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
</article>
|