rsyslog Release Numbering Scheme¶
rsyslog release numbers follow the 8.yymm.0 pattern so users can instantly judge how current a build is while keeping long-standing compatibility promises and a predictable release day. .. summary-end
Overview¶
Since January 2019 rsyslog has used a calendar-based identifier that is easy to read at a glance:
8— the long-running major series. Staying on the same major digit signals that no breaking architectural shift has taken place. The project plans to keep8as the visible major until the numbering scheme itself changes or a non-backwards-compatible rewrite truly requires a higher digit.yymm— the two-digit year and month when the release was published. For example8.2306.0was issued in June 2023..0— the patch counter. Regular scheduled releases use.0. Urgent corrections (rare) become.1,.2, and so on.
The version string reported by rsyslogd -v mirrors this layout and
also prints a human-friendly alias such as 8.1901.0 (aka 2019.01).
Cadence and scheduling¶
Stable builds are issued roughly every two months. The release team aims for an even-numbered month (February, April, June, …) on a Tuesday around mid-month. Monday is reserved for final testing and housekeeping, while the remainder of the week provides distance from the weekend — a period when operations staff is thin and attackers are more active. Holiday seasons occasionally shift the target: for example the December release is typically earlier in the month so critical updates can be applied before Christmas downtime. Exceptional security needs or project priorities may also pull a build forward or push it back.
Quick reference for newcomers¶
If you are evaluating or deploying rsyslog, keep these checkpoints in mind:
Treat the
yymmportion as the age of your installation. A value older than about a year usually means you are missing new modules, fixes, or performance improvements.When you see the same
yymmacross different systems, they are running the same feature level regardless of packaging metadata.Patch digits greater than
0indicate that the release was respun to ship a focused fix without waiting for the next scheduled release.Major digit changes (for example moving from 8.x to 9.x someday) would signal a deliberate compatibility break and be announced separately.
Background and rationale¶
Before 2019 rsyslog labeled releases as 8.<seq>.0 where <seq> simply
counted every six-week drop. The community noticed that 8.24 versus 8.40
misleadingly looked like minor point upgrades even though they were years apart.
Switching to the calendar-inspired 8.yymm.0 notation keeps the established
major series in place for enterprise distributions while making it obvious how
fresh a package is. The decision was refined on the mailing list and summarized
on Rainer Gerhards’ project blog when the first 8.1901.0 build shipped in
January 2019. The policy has since evolved from the “roughly six-week” cadence
described in that post to today’s bi-monthly Tuesday rhythm for the reasons
outlined above.
Inspired by the wider ecosystem¶
rsyslog’s numbering mirrors other projects that encode calendar information in
their version strings, such as Ubuntu (24.04) and openEuler (25.09). The
similarity makes it easy for operators familiar with those platforms to parse
8.2404.0 at a glance and understand how it fits into their maintenance
cycle.
See also
Rainer Gerhards, rsyslog version numbering change
Support: rsyslog Assistant | GitHub Discussions | GitHub Issues: rsyslog source project
Contributing: Source & docs: rsyslog source project
© 2008–2025 Rainer Gerhards and others. Licensed under the Apache License 2.0.