Over the years we have released new Zeek (Bro) versions on a somewhat regular annual basis, often around the time of BroCon. We also often did smaller bug fix releases in between, typically without adding any new functionality. However, while this annual cycle gave Zeek users a stable version to run operationally, it also meant that sites seeking to leverage new features that hadn’t made it into a release yet, either had to wait a substantial amount of time before getting access, or were forced to switch to running an unstable development version from Zeek’s master git branch. To address this challenge, we are switching to a more frequent release cycle that combines the best of both worlds by (1) offering regular feature releases while also (2) providing dedicated longer-term stable versions for users who prioritize stability over new functionality.
Schedule
The next (and first 🙂 Zeek version will be 3.0.0, cut from git’s master branch at the time of release. It’ll be a stable version that we will support with critical bug fixes for one year, released as 3.0.x versions. During that year we will also be providing smaller feature releases 3.x.0 about every four months, again cutting them from master at that time. We’ll always support the most recent feature release with critical bug fixes (3.x.y).
About a year later, the process will repeat with stable version 4.0.0, followed by feature releases 4.x.0—and so on. For stable releases, we’ll select what we’ll deem the most solid base at that point. That could mean current master, a patched version of the most recent feature release, or even just that feature release itself. For all releases with substantial changes—feature and stable—we’ll be making beta versions available early for users to validate.
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.y.z with z > 0 are maintenance releases
Backwards Compatibility
As a key part of the new release schedule, we will strive to maintain backwards compatibility between two subsequent stable releases, usually by first deprecating legacy functionality in stable release X, and then removing it in stable release X+1. That means that users of stable 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 stable version. For example, if a feature becomes deprecated with 3.0.0, we can remove it in 3.1.0; and then also in 4.0.0.
Please note that we cannot promise 100% backwards compatibility between stable versions, as sometimes there’s just no good deprecation path without blocking development for an extended period. However, we will seek community input in cases where we need to choose.
Next Steps
Zeek 3.0.0 will be the first version to follow the new schedule. We don’t have a release date for that yet. The main remaining work items for that version are finishing the renaming, and removing any functionality that’s currently deprecated in 2.6.
RSS - Posts