Well, for a long time we only had 1 line maintained, 3.4 basically. It is just right now we have 3 lines, which is I think one too many. (Plus we also have master to maintain additional to the active release lines, that's 4 active branches. Well, more or less, 3.4 is pretty inactive already).
I pretty much agree with Andor's points. My only comment is what testing do we do to achieve number 3? (different version of client-server connectability) - Norbert On Thu, Apr 2, 2020 at 10:14 PM Christopher <ctubb...@apache.org> wrote: > On Thu, Apr 2, 2020 at 12:20 PM Patrick Hunt <ph...@apache.org> wrote: > > > > On Thu, Apr 2, 2020 at 8:15 AM Andor Molnar <an...@apache.org> wrote: > > > > > Alright. Not sure how to coordinate this properly, let’s try to discuss > > > these 3 points individually. > > > > > > 1) EOL is 1st of June, 2020 which means from this day forward 3.4 is > ... > > > - not supported by the community dev team, > > > - not accepting patches, no future releases, no security fixes, > > > - latest version is still accessible at download page for 1(?) year > > > > > > > > Apache archival process is documented on this page: > > https://www.apache.org/legal/release-policy.html#when-to-archive > > we do get nudged on it every so often: e.g. > > https://issues.apache.org/jira/browse/ZOOKEEPER-1752 > > The archival process is regarding removal of old versions from the > mirroring system. It does not apply to "current" releases ("current" > being defined as still linked from the project's download page). > > The question here is regarding the timing for removal from the > project's download page. I suggest event-based, rather than > time-based. Since ZK seems to be maintaining 3 release lines > concurrently, you could remove 3.4 when 3.7 is released, unless > there's a good reason to drop it sooner (to reduce the number of > concurrent releases supported to 2, for example). > > > > > > > > 2) Supported upgrade path is: latest 3.4 -> latest 3.5 -> latest 3.6 > > > > > > 3) Interoperability guarantees: > > > - Previous version of ZooKeeper client is able to connect to server > as > > > long as there’s no new feature enforced on server side, > > > - Previous version of ZooKeeper server is able to accept connections > > > from clients as long as they don’t want to use new features. > > > > > > > > I believe 2/3 are consistent with "Backward Compatibility" here? > > https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement > > > > Patrick > > > > > > > Thoughts? > > > > > > Andor > > > > > > > > > > > > > > > > On 2020. Apr 2., at 6:30, Michael Han <h...@apache.org> wrote: > > > > > > > > +1. > > > > > > > > For EOL policy statement, just to throw something out here that i can > > > think > > > > of: > > > > > > > > * Define what EOL means (such as: not supported by community dev team > > > > anymore, no future 3.4 releases .. still accessible at download page > for > > > X > > > > years..) and a date of EOL. > > > > > > > > * Provide guidelines for upgrading paths to 3.5 / 3.6. > > > > > > > > * State interoperability guarantees another post pointed out > previously ^ > > > > > > > > On Wed, Apr 1, 2020 at 2:04 AM Andor Molnar <an...@apache.org> > wrote: > > > > > > > >> Hi folks, > > > >> > > > >> Based on Enrico’s latest post about a 3.4 client problem I’d like to > > > push > > > >> this initiative. > > > >> Asking more senior members of the community what communicated > policy is > > > >> needed exactly to say 3.4 is EoL? > > > >> > > > >> In terms of timing I’d like Patrick’s suggestion about 1st of June, > > > 2020. > > > >> > > > >> Any objections? > > > >> > > > >> Andor > > > >> > > > >> > > > >> > > > >> > > > >>> On 2020. Mar 4., at 18:45, Michael K. Edwards < > m.k.edwa...@gmail.com> > > > >> wrote: > > > >>> > > > >>> I think it would be useful for an EOL statement about 3.4.x to > include > > > a > > > >>> policy on interoperability of newer ZooKeeper servers with 3.4.x > client > > > >>> code. Stacks that build on top of Kafka and Hadoop (I'm looking at > > > you, > > > >>> Spark) often wind up having an indirect dependency on a comically > stale > > > >>> ZooKeeper library. Even if this library isn't really exercised by > the > > > >>> client side of the stack, it's there in the mountain of jars; and > when > > > >>> application code also wants to use ZooKeeper more directly, using a > > > newer > > > >>> client library can get kind of messy. The approach I've taken has > been > > > >> to > > > >>> rebuild large swathes of the stack around a consistent, recent > > > ZooKeeper > > > >>> build; but I think it would be relevant to a lot of people to know > > > >> whether, > > > >>> say, a 3.4.14 client will work reliably with a 3.6.x quorum. > > > >>> > > > >>> On Wed, Mar 4, 2020 at 9:28 AM Enrico Olivelli < > eolive...@gmail.com> > > > >> wrote: > > > >>> > > > >>>> Il giorno mer 4 mar 2020 alle ore 17:23 Patrick Hunt > > > >>>> <ph...@apache.org> ha scritto: > > > >>>>> > > > >>>>> It seems like we should have a stated/communicated policy around > > > >> release > > > >>>>> lifecycles before sending an EOL message. That way folks have > some > > > >> runway > > > >>>>> to plan for the event, both near term (3.4) as well as long term. > > > >>>> > > > >>>> Shall we set a deadline ? > > > >>>> Something like "3.4 will be EOL by the end of 2020" ? > > > >>>> At this point we are only "discussing" about sending 3.4 to EOL, > no > > > >>>> decision has been made yet > > > >>>> > > > >>>> > > > >>>> Enrico > > > >>>> > > > >>>> > > > >>>>> > > > >>>>> Patrick > > > >>>>> > > > >>>>> On Wed, Mar 4, 2020 at 5:16 AM Szalay-Bekő Máté < > > > >>>> szalay.beko.m...@gmail.com> > > > >>>>> wrote: > > > >>>>> > > > >>>>>> Also a minor thing to consider: we wanted to ask the HBase > community > > > >> to > > > >>>>>> upgrade to ZooKeeper 3.5 before, and the conclusion there was > that > > > >> they > > > >>>>>> will do so only when the EOL will be at least scheduled / > announced > > > on > > > >>>> the > > > >>>>>> ZooKeeper 3.4 versions. Maybe there are other ZooKeeper users as > > > well > > > >>>> who > > > >>>>>> will not upgrade until they get 'an official' statement about > the > > > 3.4 > > > >>>>>> versions. > > > >>>>>> > > > >>>>>> On Wed, Mar 4, 2020 at 1:44 PM Jordan Zimmerman < > > > >>>>>> jor...@jordanzimmerman.com> > > > >>>>>> wrote: > > > >>>>>> > > > >>>>>>> I'm +1 on this. We're planning to drop support for 3.4.x in the > > > next > > > >>>>>>> release of Apache Curator, FYI. > > > >>>>>>> > > > >>>>>>> -Jordan > > > >>>>>>> > > > >>>>>>>> On Mar 4, 2020, at 7:36 AM, Enrico Olivelli < > eolive...@gmail.com> > > > >>>>>> wrote: > > > >>>>>>>> > > > >>>>>>>> Hi, > > > >>>>>>>> we are releasing 3.6.0 (I am waiting for mirrors to sync > before > > > >>>>>>>> updating the website). > > > >>>>>>>> > > > >>>>>>>> In my opinion it is time to officially send 3.4 branch to EOL > > > >>>> status, > > > >>>>>>> that is: > > > >>>>>>>> - we are not expecting new releases > > > >>>>>>>> - drop 3.4 from download area (it will stay on archives as > usual) > > > >>>>>>>> - strongly encourage people to update to 3.5/3.6 > > > >>>>>>>> > > > >>>>>>>> 3.4 is far away from master branch and even from 3.6. > > > >>>>>>>> There is a clean upgrade path from 3.4.LATEST to 3.5.7 and to > 3.6 > > > >>>> so > > > >>>>>>>> users are able to upgrade. > > > >>>>>>>> > > > >>>>>>>> I am not sure we need a VOTE, if we simply agree I can drop > 3.4 > > > >>>> from > > > >>>>>>>> the "dist" are as long as I push the new website. > > > >>>>>>>> > > > >>>>>>>> Best regards > > > >>>>>>>> Enrico > > > >>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>> > > > >> > > > >> > > > > > > >
