shorewall_code/Shorewall-docs2/ReleaseModel.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
  <!--$Id$-->

  <articleinfo>
    <title>Shorewall Release Model</title>

    <authorgroup>
      <author>
        <firstname>Tom</firstname>

        <surname>Eastep</surname>
      </author>
    </authorgroup>

    <pubdate>2004-07-03</pubdate>

    <copyright>
      <year>2004</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>
    <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 new features are added to
        stable releases and new minor releases of a stable release will only
        contain bug fixes. Installing a new minor release for the major
        release that you are currently running involves no migration issues
        (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://lists.shorewall.net">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&#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>
      </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>
    </orderedlist>

    <para>The currently-supported major releases are 1.4 and 2.0.</para>
  </section>

  <section>
    <title>Old Release Model</title>

    <para>This release model described above was adopted on 2003-07-03. Prior
    to that time, 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>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 was
        necessary to accept new functionailty along with the bug fix.</para>
      </listitem>
    </orderedlist>
  </section>
</article>