Almost all Curator users should be unaffected. But, I should probably do some random checking on Github. The only ones affected are:
Those who want/need to stay on ZK 3.4 - they shouldn't upgrade to Curator 5.0 Clients using Curator's Reaper/ChildReaper classes. These clients should change to container nodes. Any client code that uses Curator's ListenerContainer. This was an internal class but maybe some people have used it. Any remaining Exhibitor users - Exhibitor has been dead for a long time. Those that still need support can stay on Curator 4.x. -Jordan > On Mar 15, 2020, at 1:59 AM, Enrico Olivelli <[email protected]> wrote: > > In your vision, will Curator 5 be compatible with 'simple' applications > written for Curator 4? > Curator is like Zookeeper, you can end up with having several libraries that > rely on it. > If we don't keep compatibility in order to update to 5 you need every other > library to move to 5 and they won't move to 5 because they have many users on > 4. > > We should deal carefully with this problem > > Btw obviously a great +2 to moving to zk 3.6.0 > > Enrico > > Il Sab 14 Mar 2020, 23:34 shay shimony <[email protected] > <mailto:[email protected]>> ha scritto: > Sorry for the late reply. > +1 from me too. > > On Wed, Mar 4, 2020, 04:37 Jordan Zimmerman <[email protected] > <mailto:[email protected]>> > wrote: > > > Hi Folks, > > > > I mentioned this a while back, but now the ZooKeeper 3.6.0 is out I'd like > > to make it official. I propose we move to Curator 5.0 and apply a few > > non-backward compatible changes - i.e. take the opportunity to fix some > > tech debt. See CURATOR-558 > > <https://issues.apache.org/jira/browse/CURATOR-558 > > <https://issues.apache.org/jira/browse/CURATOR-558>> for details. Any > > objections? > > > > -Jordan > >
