Release Cadence

Types of Releases

We strive to maintain a balance between providing quick access to new Zeek functionality for users willing to upgrade frequently, as well as long-term stability for those preferring less interruption to their operational setup. To that end, we maintain two separate release tracks:

1. About every four months, we publish a feature release cut from the current development tree. A feature release may be somewhat disruptive to current users due to the introduction of new features and changes to existing functionality, but otherwise we consider these releases stable and ready for production usage. For the current feature release, we will provide further maintenance updates with important fixes as needed.

2. About every year, we publish a long-term support (LTS) release that, over the course of that year we will support with further maintenance updates containing important fixes. Once a new LTS release comes out, we will stop maintaining the previous one after one further feature release on top of that new LTS. In other words: if you are staying on the LTS track, you will have about 4 months to upgrade after a new LTS release comes out.

For any releases coming with major changes to functionality, we publish release candidates before their final versions go out, so that users get a chance to provide feedback. Typically, we provide a release candidate about two weeks ahead of the actual release.

Versioning

Each new LTS release carries an updated major version: 5.0.0, 6.0.0, 7.0.0, etc. For the current LTS version, we then publish subsequent maintenance releases as patch versions (e.g., 6.0.1, 6.0.2, 6.0.3).

Feature releases retain the major version of the current LTS release but increase the minor version with each release (e.g., 6.1.0, 6.2.0). Any further maintenance updates to a feature release increase its patch level (e.g., 6.1.1, 6.1.2, 6.1.3).

For release candidates, the version will match that of the upcoming release, with -rcN appended (e.g., 6.1.0-rc1).

Finally, if you happen to see a version number x.y.z-dev.NNN, then that's an unstable development version from the git repository. Such a version number indicates that this development version will eventually become release version x.y.z, and that so far NNN commits have gone into the development since the previous feature release. As an example, 6.1.0-dev.NNN will eventually turn into 6.1.0-rc1, then into 6.1.0.

Backwards Compatibility

For all user-visible functionality we strive to maintain backwards compatibility between two subsequent LTS releases, usually by first deprecating legacy functionality in LTS release X.0.0 and then removing it in LTS release (X+1).0.0 at the latest. This means that users of LTS versions will have a year to adapt their installations before functionality becomes unavailable. The in-between feature releases will go ahead and take out functionality that’s cleared for removal with the next LTS version. X.1.0, in particular, often removes deprecated functionality.

For example, if a feature becomes deprecated with 6.0.0, we can remove it in 6.1.0. However, a feature deprecated in 6.1.0 will not go out before 7.1.0.

We call out deprecated functionality in a dedicated section in the release notes and the NEWS file. Make sure to review it.

Please note that we cannot promise 100% backwards compatibility between LTS versions as sometimes there’s just no good deprecation path without blocking development for an extended period. We will seek community input on the Zeek user mailing list in cases where we need to choose.

Versioning Summary

In short:

• x.0.0 are stables releases with one year of support
• x.y.0 with y > 0 are feature releases with about 4 months of support
• x.1.0 frequently removes deprecated functionality
• x.y.z with z > 0 are maintenance updates
• x.y.z-rcN is the N-th release candidate for x.y.z
• x.y.z-dev.NNN are unstable, non-release versions with no support

Git tagging

The following diagram illustrates how versioning is reflected in git tags in the toplevel repository.