diff --git a/Shorewall-docs2/ReleaseModel.xml b/Shorewall-docs2/ReleaseModel.xml
index babdcdad8..b5059c88a 100644
--- a/Shorewall-docs2/ReleaseModel.xml
+++ b/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>
-        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&#39;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>
+        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>
@@ -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,...
-        . 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>
+        <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>
diff --git a/Shorewall-docs2/support.xml b/Shorewall-docs2/support.xml
index c7e3ce8ee..80b4184df 100644
--- a/Shorewall-docs2/support.xml
+++ b/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>
@@ -304,4 +304,4 @@
     url="http://lists.shorewall.net">http://lists.shorewall.net</ulink>
     .</para>
   </section>
-</article>
+</article>
\ No newline at end of file