[syslog-ng] [Bug 93] filter() functionality between 2.1 to 3.0 not consistent

[bugzilla at bugzilla.balabit.com]

https://bugzilla.balabit.com/show_bug.cgi?id=93


Balazs Scheidler <bazsi at balabit.hu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|                            |WONTFIX
             Status|NEW                         |RESOLVED




--- Comment #3 from Balazs Scheidler <bazsi at balabit.hu>  2010-09-23 07:47:26 ---

The feature-release/stable-release distinction was created for our commercial 
products (not just syslog-ng, but we have others too) and at first it seemed logical to do
the same for our open source projects as well.

Fast forward with about a year and now I think that it may not make as much sense for the
open source projects, because we don't have enough resources to maintain 3 branches
in parallel, and doing that certainly decreases the time we have for new 
features/innovations.

All that said, it is important to point out that for us developers a feature release is not
different from a "stable" release except for the support period. (stable releases were 
supported until the next 2 stable releases, e.g. 3.0 would be supported until 5.0).

So it is not the same model as the kernel used (even for stable, odd for unstable). In 
the status quo (e.g. forgetting what I wrote in the previous paragraphs) 3.1 is receiving 
maintenance changes _only_. 

Development is happening in the 3.2 branch, right now at 3.2alpha2.

So yes, I'd consider syslog-ng 3.1 production ready and in some ways much better than 
3.0 (for example in the problem you've found).

But all that said, it is possible to work around this problem in 3.0 by using:

* the message() filter; or
* match(value("MESSAGE")) in @version 3.0 mode (where MESSAGE is equal to MSGONLY)

instead of using the match(... value(MSGONLY)) construct. The problem is really that the
value() options only work for name-value pairs and not for macros. This distinction is difficult
to make, that's why 3.1 already warns about these. ($DATE is a macro, $HOST is a name-value pair).


-- 
Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.