Update major releases

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1927 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb

Shorewall-docs2/ReleaseModel.xml

@@ -15,11 +15,13 @@
       </author>
     </authorgroup>
 
-    <pubdate>2004-07-21</pubdate>
+    <pubdate>2005-02-01</pubdate>
 
     <copyright>
       <year>2004</year>
 
+      <year>2005</year>
+
       <holder>Thomas M. Eastep</holder>
     </copyright>
 
@@ -29,7 +31,8 @@
       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>
+      <quote><ulink url="GnuCopyright.htm">GNU Free Documentation
+      License</ulink></quote>.</para>
     </legalnotice>
   </articleinfo>
 
@@ -88,21 +91,22 @@
         <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>
+        the form <emphasis>x.y.0-BetaN</emphasis> where
-        is the number of the next Stable Release and <emphasis>N</emphasis>=1,2,3...
+        <emphasis>x.y</emphasis> is the number of the next Stable Release and
-        . Betas are expected to occur rougly once per year. Beta releases may
+        <emphasis>N</emphasis>=1,2,3... . Betas are expected to occur rougly
-        contain new functionality not present in the previous beta release
+        once per year. Beta releases may contain new functionality not present
-        (e.g., 2.2.0-Beta4 may contain functionality not present in
+        in the previous beta release (e.g., 2.2.0-Beta4 may contain
-        2.2.0-Beta3). When I&#39;m confident that the current Beta release is
+        functionality not present in 2.2.0-Beta3). When I'm confident that the
-        stable, I will release the first <firstterm>Release Candidate</firstterm>.
+        current Beta release is stable, I will release the first
-        Release candidates have identifications of the form
+        <firstterm>Release Candidate</firstterm>. Release candidates have
-        <emphasis>x.y.0-RCn</emphasis> where <emphasis>x.y</emphasis> is the
+        identifications of the form <emphasis>x.y.0-RCn</emphasis> where
-        number of the next Stable Release and <emphasis>n</emphasis>=1,2,3...
+        <emphasis>x.y</emphasis> is the number of the next Stable Release and
-        . Release candidates contain no new functionailty -- they only contain
+        <emphasis>n</emphasis>=1,2,3... . Release candidates contain no new
-        bug fixes. When the stability of the current release candidate is
+        functionailty -- they only contain bug fixes. When the stability of
-        judged to be sufficient then that release candidate will be released
+        the current release candidate is judged to be sufficient then that
-        as the new stable release (e.g., 2.2.0). At that time, the new stable
+        release candidate will be released as the new stable release (e.g.,
-        release and the prior stable release are those that are supported.</para>
+        2.2.0). At that time, the new stable release and the prior stable
+        release are those that are supported.</para>
       </listitem>
 
       <listitem>
@@ -119,7 +123,7 @@
       </listitem>
     </orderedlist>
 
-    <para>The currently-supported major releases are 1.4 and 2.0.</para>
+    <para>The currently-supported major releases are 2.0 and 2.2.</para>
   </section>
 
   <section>
@@ -144,10 +148,11 @@
       <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,...
+        <emphasis>x.y.zX</emphasis> (e.g., 2.0.3c) where
-        . Consequently, if a user required a bug fix but was not running the
+        <emphasis>X</emphasis>=1,b,c,... . Consequently, if a user required a
-        last minor release of the associated major release then it might be
+        bug fix but was not running the last minor release of the associated
-        necessary to accept major new functionailty along with the bug fix.</para>
+        major release then it might be necessary to accept major new
+        functionailty along with the bug fix.</para>
       </listitem>
     </orderedlist>
   </section>

Shorewall-docs2/support.xml

@@ -15,10 +15,10 @@
       </author>
     </authorgroup>
 
-    <pubdate>2004-10-12</pubdate>
+    <pubdate>2005-01-24</pubdate>
 
     <copyright>
-      <year>2001-2004</year>
+      <year>2001-2005</year>
 
       <holder>Thomas M. Eastep</holder>
     </copyright>
@@ -49,7 +49,7 @@
     <itemizedlist>
       <listitem>
         <para>The two currently-supported Shorewall <ulink
-        url="ReleaseModel.html">major releases</ulink> are 1.4 and 2.0.</para>
+        url="ReleaseModel.html">major releases</ulink> are 2.0 and 2.2.</para>
       </listitem>
 
       <listitem>