Effective today, Shorewall is adopting a new release model which is
patterned after the one used in the Linux Kernel.
1. Releases continue to have a three-level identification x.y.z
(e.g., 2.0.3).
2. The first two levels (x.y) designate the Major Release Number
(e.g., 2.0)
3. The third level (z) designates the Minor Release Number.
4. Even numbered major releases (e.g., 1.4, 2.0, 2.2, ...) are
Stable Releases. 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). Note this is different from the Linux
Kernel -- there, new minor stable releases *do* contain new functionality.
5. Support is available through the Mailing List for the two most
recent Stable Releases.
6. Odd numbered major releases (e.g., 2.1, 2.3, ...) are Development
Releases. 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 Shorewall Development Mailing List.
7. When the level of functionality of the current development
release is judged adaquate, the Beta period for a new Stable release
will begin. Beta releases have identifications of the form x.y.0-BetaN
where x.y is the number of the next Stable Release and N=1,2,3... .
Betas are expected to occur roughly 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 Release Candidate. Release candidates
have identifications of the form x.y.0-RCn where x.y is the number of
the next Stable Release and n=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.
8. What does it mean for a major release to be supported? 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.
9. Between minor releases, bug fixes will continue to be made
available through the Errata page for each major release.
The immediate implications of this change are as follows:
1. The functionality of the 2.0 major release is frozen at the level
of minor release 2.0.3.
2. The two major releases currently supported are 1.4 and 2.0.
3. I will be opening the 2.1 development release shortly with the
release of 2.1.0.
4. Bug-fix releases with identifications of the form x.y.zX where
X=a,b,c,... (e.g., 2.0.3c) will not be seen in the future.
I hope that this new model will eliminate some of the rapid-fire
bug-fixes that we''ve seen recently and will encourage users to keep
current with minor releases.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net