• Home
• Products
• syslog-ng
• Open source
• Roadmap

• Purchasing
• Information
• Print
• Send to mail

Roadmap - plans for the future

Release policy changes

With the advent of syslog-ng Open Source Edition 3.0 a new release policy is formed. A condensed summary of the release policy follows here, a more formal description will follow later.

Up until 3.0, syslog-ng used long development cycles, a given major release (like 2.0 or 2.1) was supported for several years. In order to accomodate minor feature requests, the maintenance releases for stable branches almost always included enhancements as well as bugfixes. This policy sometimes caused some destabilization of the stable branch and also meant that more risky changes had no place to be integrated into, they were simply sitting around till the next branch of the next major version opened.

The new policy is changing the practices outlined above: instead of large, monolithic major versions with long development cycles, smaller, feature based versions are going to be published, and more frequently.

Since more frequent major releases would increase the number of versions supported in parallel rapidly, a two level support status is introduced:

• Stable track versions: denoted by .0 version number (e.g. 2.0 or 3.0), these are supported for at least 1 year, but no more than 2 stable releases are supported at a time.
• Feature track versions: denoted by a non-zero version number (e.g. 3.1, 3.2 and onwards). This is where the new features are published, presumably 1-3 new feature per release. Only the last of the feature track releases is supported (e.g. when a new feature track release comes out, the last one becomes unsupported), and the last feature track release becomes the new stable.

Please note that feature track versions go through the same kind of testing as the stable versions, thus they are by no means "unstable" development snapshots. The only difference between earlier major releases and current feature releases is the smaller number of features they contain and the shorter support periods. Unstable snapshots and alpha/beta/rc releases will be marked explicitly as such.

Also note, that the means to support either stable track or feature track versions is to release maintenance (e.g. bugfix) releases. These bugfix releases have 3 digits in their version number, just like previously.

As a summary, this is the interpretation of syslog-ng version numbers of the future:

• syslog-ng 4.0: stable track syslog-ng branch, maintenance releases are published with a 3rd version number added
• syslog-ng 4.0.2: the 2nd maintenance release of the syslog-ng 4.0 branch
• syslog-ng 4.1: feature track syslog-ng branch, maintenance releases are published with a 3rd version number added
• syslog-ng 4.1.2: the 2nd maintenance release of the syslog-ng 4.1 branch

Plans for 4.0

Per the description above, here comes the plans for syslog-ng 4.0, broken down to feature releases. As always with free software things are not set in stone.

syslog-ng 3.1

• support tags for syslog messages: each message can be marked with one or more tags, then apply filtering based on tags
• patterndb: add tag support
• patterndb: v2 database format support
• patterndb: add parsers for IPv6 addresses and hex numbers
• converge macros in templates and name-value pairs even more (right now it is not possible to use any macro in match())

syslog-ng 3.2

• rewrite support for non-string fields (facility and severity)
• patterndb: add SQL schema information on a per-tag basis
• add generic SQL destination that uses the schema information from patterndb

syslog-ng 3.3

• portable syslog() API extension to support the new protocol
• the ability to manipulate structured data fields