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 2017/07/24 05:01:29 UTC

DISCUSS: Remove Classic connection handling

Background: We are preparing to release what will be Apache Curator 4.0.0. As usual, our tests are a bit flakey. Currently, the biggest culprit is "classic" connection handling. This is a special internal mode that most people probably don't even know about. It was added as a backward compatibility stop gap when the meaning of connection state LOST changed from Curator 2.x to Curator 3.x. With Curator 4.0, I'd like to completely remove "classic" connection handling unless there are objections. Here is the PR:

	https://github.com/apache/curator/pull/233 <https://github.com/apache/curator/pull/233>

Please comment on the PR if you have any issues with this. I'll leave this open for 48 hours - i.e. barring objections this will get merged Wednesday morning US time.

-Jordan

Re: DISCUSS: Remove Classic connection handling

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
It will show in the release notes.

> On Jul 24, 2017, at 8:28 AM, Mike Drob <md...@apache.org> wrote:
> 
> To clarify, this means that folks still on Curator 2.x will see a change in
> behavior if they go straight to 4.x? It's a major version, so that should
> be fine but let's make sure it shows up in the release notes.
> 
> On Mon, Jul 24, 2017 at 12:01 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
> 
>> Background: We are preparing to release what will be Apache Curator 4.0.0.
>> As usual, our tests are a bit flakey. Currently, the biggest culprit is
>> "classic" connection handling. This is a special internal mode that most
>> people probably don't even know about. It was added as a backward
>> compatibility stop gap when the meaning of connection state LOST changed
>> from Curator 2.x to Curator 3.x. With Curator 4.0, I'd like to completely
>> remove "classic" connection handling unless there are objections. Here is
>> the PR:
>> 
>>        https://github.com/apache/curator/pull/233 <
>> https://github.com/apache/curator/pull/233>
>> 
>> Please comment on the PR if you have any issues with this. I'll leave this
>> open for 48 hours - i.e. barring objections this will get merged Wednesday
>> morning US time.
>> 
>> -Jordan


Re: DISCUSS: Remove Classic connection handling

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
It will show in the release notes.

> On Jul 24, 2017, at 8:28 AM, Mike Drob <md...@apache.org> wrote:
> 
> To clarify, this means that folks still on Curator 2.x will see a change in
> behavior if they go straight to 4.x? It's a major version, so that should
> be fine but let's make sure it shows up in the release notes.
> 
> On Mon, Jul 24, 2017 at 12:01 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
> 
>> Background: We are preparing to release what will be Apache Curator 4.0.0.
>> As usual, our tests are a bit flakey. Currently, the biggest culprit is
>> "classic" connection handling. This is a special internal mode that most
>> people probably don't even know about. It was added as a backward
>> compatibility stop gap when the meaning of connection state LOST changed
>> from Curator 2.x to Curator 3.x. With Curator 4.0, I'd like to completely
>> remove "classic" connection handling unless there are objections. Here is
>> the PR:
>> 
>>        https://github.com/apache/curator/pull/233 <
>> https://github.com/apache/curator/pull/233>
>> 
>> Please comment on the PR if you have any issues with this. I'll leave this
>> open for 48 hours - i.e. barring objections this will get merged Wednesday
>> morning US time.
>> 
>> -Jordan


Re: DISCUSS: Remove Classic connection handling

Posted by Mike Drob <md...@apache.org>.
To clarify, this means that folks still on Curator 2.x will see a change in
behavior if they go straight to 4.x? It's a major version, so that should
be fine but let's make sure it shows up in the release notes.

On Mon, Jul 24, 2017 at 12:01 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> Background: We are preparing to release what will be Apache Curator 4.0.0.
> As usual, our tests are a bit flakey. Currently, the biggest culprit is
> "classic" connection handling. This is a special internal mode that most
> people probably don't even know about. It was added as a backward
> compatibility stop gap when the meaning of connection state LOST changed
> from Curator 2.x to Curator 3.x. With Curator 4.0, I'd like to completely
> remove "classic" connection handling unless there are objections. Here is
> the PR:
>
>         https://github.com/apache/curator/pull/233 <
> https://github.com/apache/curator/pull/233>
>
> Please comment on the PR if you have any issues with this. I'll leave this
> open for 48 hours - i.e. barring objections this will get merged Wednesday
> morning US time.
>
> -Jordan

Re: DISCUSS: Remove Classic connection handling

Posted by Mike Drob <md...@apache.org>.
To clarify, this means that folks still on Curator 2.x will see a change in
behavior if they go straight to 4.x? It's a major version, so that should
be fine but let's make sure it shows up in the release notes.

On Mon, Jul 24, 2017 at 12:01 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> Background: We are preparing to release what will be Apache Curator 4.0.0.
> As usual, our tests are a bit flakey. Currently, the biggest culprit is
> "classic" connection handling. This is a special internal mode that most
> people probably don't even know about. It was added as a backward
> compatibility stop gap when the meaning of connection state LOST changed
> from Curator 2.x to Curator 3.x. With Curator 4.0, I'd like to completely
> remove "classic" connection handling unless there are objections. Here is
> the PR:
>
>         https://github.com/apache/curator/pull/233 <
> https://github.com/apache/curator/pull/233>
>
> Please comment on the PR if you have any issues with this. I'll leave this
> open for 48 hours - i.e. barring objections this will get merged Wednesday
> morning US time.
>
> -Jordan