Il giorno dom 15 mar 2020 alle ore 14:47 Jordan Zimmerman
<[email protected]> ha scritto:
>
> 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.
>
>

Good, thanks for checking

Enrico


> -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]> ha scritto:
>>
>> Sorry for the late reply.
>> +1 from me too.
>>
>> On Wed, Mar 4, 2020, 04:37 Jordan Zimmerman <[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> for details. Any
>> > objections?
>> >
>> > -Jordan
>> >
>
>

Reply via email to