[Snort-sigs] [Emerging-Sigs] [Snort-devel] Snort 184.108.40.206 Now Available
rcombs at ...435...
Wed Nov 3 14:33:09 EDT 2010
Thanks, Mike, for the objective explanation.
On Wed, Nov 3, 2010 at 12:46 PM, Mike Lococo <mikelococo at ...2420...> wrote:
> > This is for /rules/, remember. Current version, and one back is the
> > standard. We'll take a look at the life cycle, wording, and policy on
> > the website to see if any modifications need to be made to clarify
> I think most folks would rather have the practice changed to match the
> written policy than the other way around. That is: rule support for the
> current version and one *major* version back.
> > We can't bring the 2.9.0 or 220.127.116.11 improvements back to 2.8.x. 2.9.0
> > was a big rewrite of the stream model (and many other things) and
> > bringing back the code to 2.8 would, as I said, be a monumental
> > undertaking. That's why 2.9 was released.
> Software-upgrades and security-fixes is a slightly different issue from
> rule-availability, although their timelines should be aligned. An
> excellent model that many companies use is to put new features into the
> latest major-release (2.9.x, at the moment), and security-fixes only for
> the previous release (2.8.x, at the moment). This doesn't require
> backporting features and subsystem rewrites, only security-related
> bug-fixes. Folks on 2.8 (or latest-1) would miss out on new features,
> and maybe on new detection logic that relies on those features. The
> benefit they would gain is control over when to deploy disruptive
> major-releases and a greater assurance that security-fix releases are
> not going to be disruptive.
> >> I can only imagine that SF is trying to push enterprise customers who
> >> care about lifecycle to appliances by promoting what is known to be an
> >> unworkable lifecycle policy.
> > No. That's not correct. 18.104.22.168 was released, as there were bugs in
> > 2.9.0 that we were able to resolve. Thusly the patch minor version. We
> > try to keep the system up to date to deal with the current threats and
> > enhance functionality, all the while giving our open-source community a
> > free product.
> No one is advocating that development be stopped, or saying that minor
> upgrades like 2.9 to 2.9.1 are too onerous. The difficulty for most of
> us is that major upgrades like 2.8 to 2.9 (which has a libpcap version
> dependency that's out of sync with the biggest Linux vendor in the
> world) are being forced with narrow planning and deployment windows due
> to a lifecycle policy based on frequent minor/patch releases instead of
> infrequent major releases.
> Mike Lococo
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-sigs