Hi, 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 conclusions. 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 releases. * 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 community. 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. -- Bazsi