extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-26 09:33:14 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update major releases

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1927 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-01-26 19:15:23 +00:00
parent fceb8cc250
commit 6b388d822f
2 changed files with 31 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
Shorewall-docs2/ReleaseModel.xml
View File

@ -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>

6
Shorewall-docs2/support.xml
View File

@ -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>