Is there a plan to release 7.5.x as v7-stable?

-- James
-- Sent from my mobile --

----- Reply message -----
From: "Rainer Gerhards" <rgerha...@hq.adiscon.com>
To: "rsyslog-users" <rsyslog@lists.adiscon.com>
Subject: [rsyslog] templates using local variables as a property
Date: Tue, Feb 11, 2014 2:42 PM

Right now, it's absolutely safe to consider the latest 7.5 stable. I am
just waiting to mature that ompgsql patch, then release 7.4.10 and 7.6.0 at
the same time. Ifvi hadn't have meetings all day, i'd probably already
finished the last bit of these changes.

Rainer

Rainer

Sent from phone, thus brief.
Am 11.02.2014 20:29 schrieb "David Lang" <da...@lang.hm>:

> On Tue, 11 Feb 2014, Micah Yoder wrote:
>
>  On 2/11/14 1:16 AM, Rainer Gerhards wrote:
>>
>>> This is exactly the type of thing that local variables were designed for.
>>>> But just to check, try doing $! instead of $. the variable will show up
>>>> as
>>>> part of a JSON output of $! if you do this, but it will let you test if
>>>> this is the problem
>>>>
>>>>
>>>>  local vars are not in 7.4., but I think the actual problem is a
>>> different
>>> one. In the config is:
>>>
>>>     set $.filename = "loggerstuff"
>>>
>>> but it must be
>>>
>>>     set $.filename = "loggerstuff";
>>>
>>> Note the semicolon at the end! It's a quirck, but we couldn't get away
>>> without adding the need for it.
>>>
>>
>> Yay got it....
>>
>> In the template...
>> property(name="$!test")
>>
>> if whatever.... {
>>  set $!test = "whatever";
>>  action(omfile... Dynafile... etc)
>> }
>>
>> Seems to work!  Thanks.
>>
>> Local variables will be better than the $! JSON tree because I will
>> actually use JSON in this (a different part of the config) also.
>>
>> Would it be recommended to use the latest 7.5 in production at this
>> point?  It will be stable "soon", correct?  Fortunately, we're not fully
>> relying on this setup yet, but we want to be ASAP.
>>
>
> I would say you should test the current 7.5, we don't expect any
> significant changes in it before 7.6 is released.
>
> There are many times that I've ended up running a 'dev' version in
> production because it had a feature I needed now. Rsyslog does a good job
> of keeping even the dev versions reliable, it's just that the dev versions
> are where new features are introduces, and once in a while this causes a
> problem that isn't caught before the release.
>
> Personally, I don't trust _any_ release (stable or otherwise) without
> testing it first, so the dev/prod distinction doesn't matter in that
> regard. There are projects that I won't touch any release until after it's
> been out a while because the developers routinely break things (and
> eventually fix them), but there are others where I have no worries about
> grabbing the latest git version and compiling it.
>
> Rsyslog falls in the latter category.
>
>
> All that said, the "official" answer is that it's never recommended to use
> a dev version in production :-p
>
> David Lang
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> DON'T LIKE THAT.
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Reply via email to