The stable repository is a great addition to the syslog-ng community, however, it introduces a new challenge with staying up to date. I'm wondering if anyone else has experienced the same challenges, and how they have addressed them. Also, if anyone has anything else to add to this I would like to hear it. The issue is that the configuration file /etc/syslog-ng/syslog-ng.conf  contains an exact version statement "@version:3.22" If I have a system that is using the stable repo, it will get the next release automatically, but the configuration file will not get updated automatically, and the @version number in the configuration file will no longer match the version of syslog-ng that is being used. To overcome this I think that the file /etc/syslog-ng/syslog-ng.conf should NOT be marked as a configuration file in the RPM. This way it will always be replaced with the new one when the package is upgraded. This introduces the challenge of how does a customer create custom configurations. I propose that the /etc/syslog-ng/syslog-ng.conf file should only be of the form @version:3.22 @include "scl.conf" @include "/etc/syslog-ng/conf.d/*.conf" and that the contents of the current /etc/syslog-ng/syslog-ng.conf file be moved to /etc/syslog-ng/conf.d/default.conf and that this file be marked in the RPM as a configuration file so that it is NOT replaced by the RPM upgrade process. At a minimum I think this is required to create a sustainable upgrade process. In the event that there is a backwards incompatibility in the configuration, you would have to bump the name of the syslog-ng package to syslog-ng4 to stop the automatic upgrades, and bump the version to 4.0. I think that the above is absolutely needed, but I would also like you to consider a change to the include order. I have come across situations where I need to define all of the templates first, then define the destinations etc. To allow a conf.d style inclusion of this order dependent configurations I have added the following include list to my top level syslog-ng configuration. @include 'conf.d/*.option' @include 'conf.d/*.template' @include 'conf.d/*.source' @include 'conf.d/*.destination' @include 'conf.d/*.filter' @include 'conf.d/*.rewrite' @include 'conf.d/*.log.final' @include 'conf.d/*.log' @include "conf.d/*.conf" The last one is for backwards compatibility. This way I can define all of the global options first, then the templates, then the sources, then the destinations ... etc. This allows for automated deploy tools such as puppet or ansible to drop appropriate snippets into the conf.d and get them loaded in the correct order.