This is a Long-Term Support (LTS) release, receiving critical
bug-fixes and security patches for the next year. The previous LTS
branch of Zeek 3.0.x may still receive any important security patches
for the next two months, but won't be maintained afterward.
General info about this release can be found in the release notes as
well as a previous blog post from the release-candidate phase:
I’d say it’s actually the opposite: we’re extending what’s normaly one year of support for an LTS release by another 2 months to give people some overlap. See here for our release policy: https://github.com/zeek/zeek/wiki/Release-Cadence
Ah…so…I think I’m misunderstanding something then. I’m currently on 3.2.3…which was released around December I think. As I read the email I read this as “you have two months to get off of Zeek 3”. Is this not the case?
* The core dev team will make 3.0.x (LTS) releases to patch any
security issues through April.
* The core dev team won't make any further 3.1.y or 3.2.z releases.
The release policy doesn't say anything about:
* Users need to get off particular releases: but there's risk
associated with staying unpatched or the effort of backporting
important patches themselves if they stay.
* The policy won't change: if there's an argument that convinces the
core dev team to provide patches for longer, then that's what happens.
* Other possible arrangements: where the core dev team aren't the ones
helping support older versions. E.g. some scheme of giving wider
volunteer support access to manage the older `release/` branches in
the Zeek organization's Git repo or other community-driven
forking/patching model.
My understanding of the current plan: historically, there hasn't been
as much effort to avoid breaking changes as there has been for the
3.0.x to 4.0.0 (LTS) path, so the upgrade itself is hopefully a simple
process where a two month period is enough. All plans for breaking
changes are revealed in deprecation warnings and release notes of
4.0.0, so people have more like 14+ months until 5.0.0 to adapt to any
of those more complex changes. The non-LTS branches (e.g. 3.1.x and
3.2.y) were meant for those that can do upgrades quickly and care more
about using the latest features than about long support duration.
