|Main Archive Page > Month Archives > syslog-ng-users archives|
Sounds like a good plan to me Bazsi and makes perfect sense.
I never understood why there were so many different versions and don't see
how you supported all of those at once.
On Fri, Apr 22, 2011 at 4:15 AM, Balazs Scheidler <firstname.lastname@example.org> wrote:
> First of all, sorry for being absent from this forum for the past couple
> of weeks. I've tried to focus here too sometimes, but due to health
> issues, I sometimes simply have too little time to do too much.
> But anyway, I haven't stopped thinking about the way forward, and I've
> thought I'd share my thoughts about those with you.
> Please note that this is not an official announcement, but rather a way
> to gather feedback on my plans. Everything can be changed, and after we
> get to an agreement, an "official" announcement will be sent out on the
> First of all, some status information:
> * syslog-ng 3.0, 3.1 and 3.2 have all produced stable versions, and were
> all maintained in parallel.
> * syslog-ng 3.3 is in development, with the primary aim at scaling
> syslog-ng to multiple CPUs. It has produced two alpha releases so far.
> * syslog-ng team in BalaBit is busy merging the OSE and PE editions of
> syslog-ng, in order to use a common core.
> * the team is basing their work on OSE 3.3, which has been available as
> two alpha releases and the git tree, also their tree is also published
> as a git repository.
> * while they were porting the PE functionality, they were also busy
> porting the new core to new platforms and also of course fixing bugs,
> they've found.
> * I've been helping the team in case they've found something that
> affected the open source edition as well.
> Then some news about my future plans on syslog-ng versions:
> * I feel that maintaining 3 releases while doing development of a 4th
> one is too much for me.
> * I originally planned to employ the same stable/feature release
> structure that BalaBit's commercial products are using. There, a stable
> release is maintained for a longer time (similar to Ubuntu LTS), while
> incremental feature releases are published, with shorter support periods
> (e.g. like normal Ubuntu releases).
> * The stable/feature release breakdown would mean, that 3.0 is a long
> term release, and 3.1 & 3.2 are short term releases.
> * However, this doesn't match real-life expectations, distributions use
> newer versions (and I really applaud this), but this also means that
> dropping support for versions included in major Linux distributions
> would cause disruptions.
> * I'm really happy that distributions can move faster, and I'd really
> like to speed up syslog-ng development. Instead of sticking to an old
> release and stuffing in bugfixes and minor features; publish a major
> release more often, so that features don't cause problems in stable
> * Therefore, I plan to abandon the feature/stable release breakdown
> altogether. One release will be the same as the other. I'm pledging
> support for major releases as long as:
> - there's only one release to be maintained in parallel to the
> development tree.
> - I plan to support a given major release for about a year.
> * This means, that syslog-ng support for OSE 3.0 & 3.1 will be
> discontinued, in the not too distant future. I'm planning on a 3 month
> period, in order to let people have time to prepare for the upgrade.
> E.g. I'd like to announce that these versions are going to be supported
> until 31th July, 2011.
> * The definition of "support" is of course vague, I can't provide SLAs
> or anything, but I'll do my best to help anyone who has issues with
> those versions.
> * Also, if a distribution which carries this version has an issue, I'll
> try to help, even past that EOL date, but general questions and problems
> found in those versions by users, will be advised to upgrade to a newer
> release, or to backport a specific fix themselves.
> Going forward:
> * I plan to announce a feature freeze for 3.3 and publish a beta
> version. And at the same time open the 3.4 branch for integrating all
> the stuff which has accumulated on the mailing list.
> * Hopefully we can have a stable 3.3 by the time the previous two
> releases hit their end-of-life in July.
> What if you disagree:
> * Until now, I didn't really publish "hard" EOL dates for syslog-ng OSE,
> simply because there were not that many of the parallel branches.
> However with the increase in development pace, I simply cannot keep up,
> and I hate to do a substandard job. Backporting fixes to 3 branches, is
> simply too much effort.
> * I'm happy to help building up the proper infrastructure outside of
> BalaBit if someone wants to help in maintenance, and release
> engineering. But this requires real effort from members of the
> Now, having written this down, please give your feedback, and I'm trying
> to work down my backlog and start integrating patches.
> Thanks for listening.
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> FAQ: http://www.campin.net/syslog-ng/faq.html
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng