shorewall_code/docs/ReleaseModel.xml
Jeremy Sowden c93817f30b Correct GFDL text embedded in document sources
The invariant sections clause doesn't quite match the official text.  It should
read:

  with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts

not:

  with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts

Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
2023-01-31 22:50:37 +00:00

141 lines
4.8 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>
<year>2008</year>
<year>2009</year>
<year>2010</year>
<year>2012</year>
<year>2013</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, no Front-Cover Texts, and 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., 4.5.0).</para>
</listitem>
<listitem>
<para>The first two levels (<emphasis>x.y</emphasis>) designate the
<firstterm>major release number</firstterm> (e.g., 4.5).</para>
</listitem>
<listitem>
<para>The third level (<emphasis>y</emphasis>) designates the
<firstterm>minor release Number</firstterm>.</para>
</listitem>
<listitem>
<para>Installing a new minor release involves no migration issues
unless you want to take advantage of an enhancement. For example, if
you are running 4.5.0 and I release 4.5.1, your current configuration
is 100% compatible with the new release.</para>
</listitem>
<listitem>
<para>A major release may have migration issues. These are listed in
the release notes and on the <ulink url="upgrade_issues.htm">upgrade
issues page</ulink>.</para>
</listitem>
<listitem>
<para>Support is available through the <ulink
url="http://sourceforge.net/mail/?group_id=22587">Mailing List</ulink>
for the most recent Major Release.</para>
</listitem>
<listitem>
<para>After the introduction of a new major release, support is still
available for the prior major release until the principle
distributions have upgraded to that new release. Fixes will only be
provided for the last minor release in the previous Major Release. For
example, once 4.5.0 was released, the only fixes for major issues with
4.4.27 would be released for the 4.4 series.</para>
</listitem>
<listitem>
<para>Support for the prior major release ends once the major Linux
distributions have upgraded to that release. </para>
</listitem>
<listitem>
<para>Once a minor release has been announced, work begins on the next
minor release. Periodic Beta releases are made available through
announcements on the Shorewall Development and Shorewall User mailing
lists. Those Beta releases are numberd w.x.y-Beta1, ...Beta2, etc.
Support for the Beta releases is offered through the Shorewall
Development mailing list in the form of emailed patches. There is no
guarantee of compatability between one Beta release and the next as
features are tweaked.</para>
</listitem>
<listitem>
<para>When the next minor release is functionally complete, one or
more <firstterm>release candidates</firstterm> are announced on the
Shorewall Development and Shorewall User mailing lists. These release
candidates are numbered w.x.y-RC1, ...-RC2, etc.</para>
</listitem>
<listitem>
<para>What does it mean for a major release to be
<firstterm>supported</firstterm>? It means that that if a bug is
found, we will fix the bug and include the fix in the next minor
release.</para>
</listitem>
<listitem>
<para>Between minor releases, bug fixes are made available via
<firstterm>patch releases</firstterm>. A patch release has a
four-level identification <emphasis>x.y.z.N</emphasis> where x.y.z is
the minor release being fixed and N = 1.2.3...</para>
</listitem>
</orderedlist>
<para>The currently-supported major release 4.5.</para>
</section>
</article>