You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Michael Stolz <ms...@pivotal.io> on 2017/09/05 18:04:01 UTC
Re: [VOTE] Apache Geode release - v1.2.1 RC1
GEODE-3249 is a breaking change to the client/server protocol, but it has a
property that can override whether or not to turn the breaking change on.
The plan was to release Geode 1.2.1 with the breaking change turned on, but
I spent a lot of time thinking about this over the weekend, and I came to
the conclusion that introducing a *breaking change in a patch release* is a
bad idea. Protocol breaking changes should really only occur in major
releases.
That said, because this is an important change for some users, the right
thing to do is probably to set the default for the controlling property to
enable backward compatibility, and then the users who want the change can
OPT-IN, rather than requiring users who are taking the patch release and
don't want the breaking change having to OPT-OUT.
We can switch that default behavior on the next major release.
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771
Re: [VOTE] Apache Geode release - v1.2.1 RC1
Posted by Jacob Barrett <jb...@pivotal.io>.
If this change is for security reasons I think it should be introduced in whatever way is necessary mitigate any security issues by default.
> On Sep 5, 2017, at 3:31 PM, Anthony Baker <ab...@pivotal.io> wrote:
>
> Ok, I understand and agree this approach, even though it means spinning another RC.
>
> Other thoughts?
>
> Anthony
>
>> On Sep 5, 2017, at 11:04 AM, Michael Stolz <ms...@pivotal.io> wrote:
>>
>> GEODE-3249 is a breaking change to the client/server protocol, but it has a
>> property that can override whether or not to turn the breaking change on.
>>
>> The plan was to release Geode 1.2.1 with the breaking change turned on, but
>> I spent a lot of time thinking about this over the weekend, and I came to
>> the conclusion that introducing a *breaking change in a patch release* is a
>> bad idea. Protocol breaking changes should really only occur in major
>> releases.
>>
>> That said, because this is an important change for some users, the right
>> thing to do is probably to set the default for the controlling property to
>> enable backward compatibility, and then the users who want the change can
>> OPT-IN, rather than requiring users who are taking the patch release and
>> don't want the breaking change having to OPT-OUT.
>>
>> We can switch that default behavior on the next major release.
>>
>>
>> --
>> Mike Stolz
>> Principal Engineer, GemFire Product Manager
>> Mobile: +1-631-835-4771
>
Re: [VOTE] Apache Geode release - v1.2.1 RC1
Posted by Anthony Baker <ab...@pivotal.io>.
Ok, I understand and agree this approach, even though it means spinning another RC.
Other thoughts?
Anthony
> On Sep 5, 2017, at 11:04 AM, Michael Stolz <ms...@pivotal.io> wrote:
>
> GEODE-3249 is a breaking change to the client/server protocol, but it has a
> property that can override whether or not to turn the breaking change on.
>
> The plan was to release Geode 1.2.1 with the breaking change turned on, but
> I spent a lot of time thinking about this over the weekend, and I came to
> the conclusion that introducing a *breaking change in a patch release* is a
> bad idea. Protocol breaking changes should really only occur in major
> releases.
>
> That said, because this is an important change for some users, the right
> thing to do is probably to set the default for the controlling property to
> enable backward compatibility, and then the users who want the change can
> OPT-IN, rather than requiring users who are taking the patch release and
> don't want the breaking change having to OPT-OUT.
>
> We can switch that default behavior on the next major release.
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771