[prev in list] [next in list] [prev in thread] [next in thread]
List: bro
Subject: [Zeek] Re: Zeek 4.0.0 released
From: James Lay <jlay () slave-tothe-box ! net>
Date: 2021-03-05 21:20:52
Message-ID: c80f9e0794b826dbdee7a15a5970d871bc6f486e.camel () slave-tothe-box ! net
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, 2021-03-05 at 12:05 -0800, Jon Siwek wrote:
> On Fri, Mar 5, 2021 at 6:21 AM James Lay <jlay@slave-tothe-box.net>
> wrote:
> 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 situation/plan is:
> * The core dev team will make 3.0.x (LTS) releases to patch
> anysecurity 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
> riskassociated with staying unpatched or the effort of
> backportingimportant patches themselves if they stay.* The policy
> won't change: if there's an argument that convinces thecore dev team
> to provide patches for longer, then that's what happens.* Other
> possible arrangements: where the core dev team aren't the oneshelping
> support older versions. E.g. some scheme of giving widervolunteer
> support access to manage the older `release/` branches inthe Zeek
> organization's Git repo or other community-drivenforking/patching
> model.
> My understanding of the current plan: historically, there hasn't
> beenas much effort to avoid breaking changes as there has been for
> the3.0.x to 4.0.0 (LTS) path, so the upgrade itself is hopefully a
> simpleprocess where a two month period is enough. All plans for
> breakingchanges are revealed in deprecation warnings and release
> notes of4.0.0, so people have more like 14+ months until 5.0.0 to
> adapt to anyof those more complex changes. The non-LTS branches
> (e.g. 3.1.x and3.2.y) were meant for those that can do upgrades
> quickly and care moreabout using the latest features than about long
> support duration.
> - Jon
Awesome thanks for the clarification...will be installing 4 soon enough
=E2=98=BA
James
[Attachment #5 (text/html)]
<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;" \
bgcolor="#ffffff" text="#000000" link="#686868" vlink="#000000"><div>On Fri, \
2021-03-05 at 12:05 -0800, Jon Siwek wrote:</div><blockquote type="cite" \
style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>On \
Fri, Mar 5, 2021 at 6:21 AM James Lay <<a \
href="mailto:jlay@slave-tothe-box.net">jlay@slave-tothe-box.net</a>> \
wrote:</pre><pre><br></pre><pre><blockquote type="cite" style="margin:0 0 0 .8ex; \
border-left:2px #729fcf solid;padding-left:1ex"></blockquote></pre><pre>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?</pre><pre></pre><pre><br></pre><pre>The situation/plan \
is:</pre><pre><br></pre><pre>* The core dev team will make 3.0.x (LTS) releases to \
patch any</pre><pre>security issues through April.</pre><pre>* The core dev team \
won't make any further 3.1.y or 3.2.z releases.</pre><pre><br></pre><pre>The release \
policy doesn't say anything about:</pre><pre><br></pre><pre>* Users need to get off \
particular releases: but there's risk</pre><pre>associated with staying unpatched or \
the effort of backporting</pre><pre>important patches themselves if they \
stay.</pre><pre>* The policy won't change: if there's an argument that convinces \
the</pre><pre>core dev team to provide patches for longer, then that's what \
happens.</pre><pre>* Other possible arrangements: where the core dev team aren't the \
ones</pre><pre>helping support older versions. E.g. some scheme of giving \
wider</pre><pre>volunteer support access to manage the older `release/` branches \
in</pre><pre>the Zeek organization's Git repo or other \
community-driven</pre><pre>forking/patching model.</pre><pre><br></pre><pre>My \
understanding of the current plan: historically, there hasn't been</pre><pre>as much \
effort to avoid breaking changes as there has been for the</pre><pre>3.0.x to 4.0.0 \
(LTS) path, so the upgrade itself is hopefully a simple</pre><pre>process where a two \
month period is enough. All plans for breaking</pre><pre>changes are revealed in \
deprecation warnings and release notes of</pre><pre>4.0.0, so people have more like \
14+ months until 5.0.0 to adapt to any</pre><pre>of those more complex changes. The \
non-LTS branches (e.g. 3.1.x and</pre><pre>3.2.y) were meant for those that can do \
upgrades quickly and care more</pre><pre>about using the latest features than about \
long support duration.</pre><pre><br></pre><pre>- \
Jon</pre><pre><br></pre></blockquote><div><br></div><div><br></div><div>Awesome \
thanks for the clarification...will be installing 4 soon enough \
☺</div><div><br></div><div>James</div></body></html>
--
zeek mailing list -- zeek@lists.zeek.org
To unsubscribe send an email to zeek-leave@lists.zeek.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic