The current Shorewall release model has the following characteristics: a) The last two major releases are supported. b) Only the latest major release is actively developed. c) Bug fixes are available for the prior major release but only against the last minor release. d) The last major release is advertised as the "Current Release". I''m thinking of switching to a model that is similar to the linux kernel: a) The last two even-numbered major release are supported with bug fixes available. Minor releases contain only bug fixes and no new functionality (similar to the a,b,c... bug-fix releases that we currently have). b) The odd numbered major releases are "Development Releases" -- new function goes into those releases with minor releases occuring once per month to six weeks. Those releases are supported on a best-effort basis. There is no Beta or Release Candidate releases when going from one minor release to the next. Users who use the development release are on the bleading edge. c) When the level of function and stability of the development release becomes sufficient then we will enter the Beta/Release Candidate Phase for the next even-numbered major release. I feel that this model will provide more stability for users who "just want it to work" while at the same time freeing me from having to quickly retrofit bug fixes (like the temporary file/directory vulnerability fix) into a release that is still getting the bugs worked out of new major functionality (like the iptables-save/iptables-restore integration). Comments? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
At 10:17 AM 7/2/2004, Tom Eastep wrote:>Comments?Slightly confused... can you perhaps give a couple of examples? <sheepish grin> OTOH, you''ve been doing such excellent work that my general attitude is going to be "if it works for you, go right ahead" no matter what the changes. Cheers, -- Rodolfo J. Paiz rpaiz@simpaticus.com http://www.simpaticus.com
How does this compare to the Linux kernel release method where x.even.y are production releases, and x.odd.y are development? It seems similar. -- Steve Herber herber@thing.com work: 206-221-7262 Security Engineer, UW Medicine, IT Services home: 425-454-2399 On Fri, 2 Jul 2004, Tom Eastep wrote:> The current Shorewall release model has the following characteristics: > > a) The last two major releases are supported. > b) Only the latest major release is actively developed. > c) Bug fixes are available for the prior major release but only against > the last minor release. > d) The last major release is advertised as the "Current Release". > > I''m thinking of switching to a model that is similar to the linux kernel: > > a) The last two even-numbered major release are supported with bug fixes > available. Minor releases contain only bug fixes and no new > functionality (similar to the a,b,c... bug-fix releases that we > currently have). > b) The odd numbered major releases are "Development Releases" -- new > function goes into those releases with minor releases occuring once per > month to six weeks. Those releases are supported on a best-effort basis. > There is no Beta or Release Candidate releases when going from one minor > release to the next. Users who use the development release are on the > bleading edge. > c) When the level of function and stability of the development release > becomes sufficient then we will enter the Beta/Release Candidate Phase > for the next even-numbered major release. > > I feel that this model will provide more stability for users who "just > want it to work" while at the same time freeing me from having to > quickly retrofit bug fixes (like the temporary file/directory > vulnerability fix) into a release that is still getting the bugs worked > out of new major functionality (like the iptables-save/iptables-restore > integration). > > Comments? > -Tom >
Rodolfo J. Paiz wrote:> At 10:17 AM 7/2/2004, Tom Eastep wrote: > >> Comments? > > > Slightly confused... can you perhaps give a couple of examples? > <sheepish grin> >Under the current release model: - Shorewall 1.4 is supported for bug-fixes only; bug fixes are supplied as updates to Shorewall 1.4.10 and we are up to 1.4.10g. So if you are running 1.4.8 and have a problem, the fix will require you to upgrade to 1.4.10 (and get all of the new functionality released in 1.4.9 and 1.4.10). - Shorewall 2.0 is the "current" release. Each new minor release (2.0.1, 2.0.2, ...) contains new functionality and bug fixes. Bug fixes between minor releases are handled as lettered updates (we''ve had 2.0.3a, 2.0.3b and I''m about to release 2.0.3c). - If you are running 2.0.1 and find a new bug, I''ll release a fix on 2.0.3, thus forcing you to upgrade (and get the possibly buggy new functionality). If I go to the new release model: - I will provide bug fix support for 1.4 and 2.0. The next bug fix release for 1.4 will be 1.4.11, the next bug fix for 2.0 will be 2.0.4. No new functionality will be added to 1.4 (no change) or to 2.0. - I will start working on the 2.1 "Development" release. I will make regular releases (2.1.0, 2.1.1, ...). This is where new stuff will be released; the documentation will not be up to the standard of the released threads (may be just the release notes) and bug fixes will be on a best effort basis. People running 2.1 will be expected to play an active role in testing and debugging the new features. - When I feel that 2.1.n is close to what I want for the next release, I will release 2.2.0-Beta1, Beta2, ..., RC1,...RCn and eventually 2.2.0 final. At that time, support for 1.4 will be dropped and the two supported releases will be 2.0 and 2.2. No new functionality will be added to 2.2 from that point on, and I will start a new 2.3 development thread. This model is very close to the Linux Kernel model. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> At 10:17 AM 7/2/2004, Tom Eastep wrote: > >> Comments?New release numbering ++ -- Mason Schmitt
At 02:27 PM 7/2/2004, Tom Eastep wrote:>If I go to the new release model: > >- I will provide bug fix support for 1.4 and 2.0. The next bug fix release >for 1.4 will be 1.4.11, the next bug fix for 2.0 will be 2.0.4. No new >functionality will be added to 1.4 (no change) or to 2.0.So in theory one should continue to upgrade a 2.0 installation to later 2.0.x releases as they happen, since there would be no changes in config files and no new functionality, just bug fixes? Then these upgrades should be nearly painless, right?>- When I feel that 2.1.n is close to what I want for the next release, I >will release 2.2.0-Beta1, Beta2, ..., RC1,...RCn and eventually 2.2.0 >final. At that time, support for 1.4 will be dropped and the two supported >releases will be 2.0 and 2.2. No new functionality will be added to 2.2 >from that point on, and I will start a new 2.3 development thread.The one question I have is roughly what kind of EOL one would see on something like 2.0. Roughly how much time would elapse between release of 2.0 and EOL due to the release of 2.4? Cheers, -- Rodolfo J. Paiz rpaiz@simpaticus.com http://www.simpaticus.com
Rodolfo J. Paiz wrote:> So in theory one should continue to upgrade a 2.0 installation to later > 2.0.x releases as they happen, since there would be no changes in config > files and no new functionality, just bug fixes? Then these upgrades > should be nearly painless, right? >Exactly.> > > The one question I have is roughly what kind of EOL one would see on > something like 2.0. Roughly how much time would elapse between release > of 2.0 and EOL due to the release of 2.4? >Approximately two years -- same as currently. I make major releases about once a year (the last two have been in mid-March). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Steve Herber wrote:> How does this compare to the Linux kernel release method where x.even.y are > production releases, and x.odd.y are development? It seems similar. >It''s pretty much the same. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Apparently Analagous Threads
- HOWTO: Temporary dynamic blocking with Shorewall and Portsentry
- Warning of upcoming removal of ''logunclean'' and ''dropunclean'' interface options.
- URGENT: Shorewall Security Vulnerability
- Shorewall CA Certificate
- [Fwd: Re: Shorewall 1.4.6: common chain rules are applied before policyrules?]