You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Jordan Zimmerman <jo...@jordanzimmerman.com> on 2020/03/04 02:37:12 UTC
PROPOSAL: Curator 5.0
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
Re: PROPOSAL: Curator 5.0
Posted by Cameron McKenzie <ca...@apache.org>.
+1 from me.
On Wed, Mar 4, 2020 at 1:37 PM Jordan Zimmerman <jo...@jordanzimmerman.com>
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
>
Re: PROPOSAL: Curator 5.0
Posted by Cameron McKenzie <ca...@apache.org>.
+1 from me.
On Wed, Mar 4, 2020 at 1:37 PM Jordan Zimmerman <jo...@jordanzimmerman.com>
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
>
Re: PROPOSAL: Curator 5.0
Posted by Enrico Olivelli <eo...@gmail.com>.
Il giorno dom 15 mar 2020 alle ore 14:47 Jordan Zimmerman
<jo...@jordanzimmerman.com> 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 <eo...@gmail.com> 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 <sh...@gmail.com> ha scritto:
>>
>> Sorry for the late reply.
>> +1 from me too.
>>
>> On Wed, Mar 4, 2020, 04:37 Jordan Zimmerman <jo...@jordanzimmerman.com>
>> 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
>> >
>
>
Re: PROPOSAL: Curator 5.0
Posted by Enrico Olivelli <eo...@gmail.com>.
Il giorno dom 15 mar 2020 alle ore 14:47 Jordan Zimmerman
<jo...@jordanzimmerman.com> 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 <eo...@gmail.com> 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 <sh...@gmail.com> ha scritto:
>>
>> Sorry for the late reply.
>> +1 from me too.
>>
>> On Wed, Mar 4, 2020, 04:37 Jordan Zimmerman <jo...@jordanzimmerman.com>
>> 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
>> >
>
>
Re: PROPOSAL: Curator 5.0
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <eo...@gmail.com> 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 <shayshim@gmail.com <ma...@gmail.com>> ha scritto:
> Sorry for the late reply.
> +1 from me too.
>
> On Wed, Mar 4, 2020, 04:37 Jordan Zimmerman <jordan@jordanzimmerman.com <ma...@jordanzimmerman.com>>
> 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
> >
Re: PROPOSAL: Curator 5.0
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <eo...@gmail.com> 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 <shayshim@gmail.com <ma...@gmail.com>> ha scritto:
> Sorry for the late reply.
> +1 from me too.
>
> On Wed, Mar 4, 2020, 04:37 Jordan Zimmerman <jordan@jordanzimmerman.com <ma...@jordanzimmerman.com>>
> 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
> >
Re: PROPOSAL: Curator 5.0
Posted by Enrico Olivelli <eo...@gmail.com>.
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 <sh...@gmail.com> ha scritto:
> Sorry for the late reply.
> +1 from me too.
>
> On Wed, Mar 4, 2020, 04:37 Jordan Zimmerman <jo...@jordanzimmerman.com>
> 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
> >
>
Re: PROPOSAL: Curator 5.0
Posted by Enrico Olivelli <eo...@gmail.com>.
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 <sh...@gmail.com> ha scritto:
> Sorry for the late reply.
> +1 from me too.
>
> On Wed, Mar 4, 2020, 04:37 Jordan Zimmerman <jo...@jordanzimmerman.com>
> 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
> >
>
Re: PROPOSAL: Curator 5.0
Posted by shay shimony <sh...@gmail.com>.
Sorry for the late reply.
+1 from me too.
On Wed, Mar 4, 2020, 04:37 Jordan Zimmerman <jo...@jordanzimmerman.com>
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
>
Re: PROPOSAL: Curator 5.0
Posted by shay shimony <sh...@gmail.com>.
Sorry for the late reply.
+1 from me too.
On Wed, Mar 4, 2020, 04:37 Jordan Zimmerman <jo...@jordanzimmerman.com>
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
>