On Thu, Apr 2, 2020 at 1: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 text is pretty unequivocal and not what you are saying. "downloads.apache.org should contain *the latest release in each branch that is currently under development*. When development ceases on a version branch, releases of that branch should be removed from the project's download directory." Meaning it should go to archive only once the branch is no longer under active development, not that it would be "removed". The semantics btw archive and remove are different. I don't think we should ever truly "remove" anything once we've officially released it. eg. you can still find 3.3 on the archive site if you want it. Patrick > 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 > > > >>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>> > > > >> > > > >> > > > > > > >
