Questions about patch releases and changes in serialization versions / messages

[Alberto Gomez <al...@est.tech>]

Hi,

The recently approved RFC about patch releases (https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases) says the following about what changes should and should not be backported to a support branch:

What changes should be back ported to a support branch?

The community will exercise good judgement in the same way that important changes are cherry-picked onto release branches prior to shipping a new release.  Fixes related to data safety and consistency, cluster stability, or API behaviors are good candidates to be considered.

What changes should NOT be back ported to a support branch?

New features, refactoring changes, or less important and non-critical bug fixes.  Of course, you are always free to advocate within the community and state your case!

This raises a question on whether changes that fall on the first category according to the above guidelines but also contain, changes in Data Serialization (for example adding/removing fields from a DataSerializable class) would still be allowed to be backported to a support branch.

If the answer is affirmative, I wonder if/how the backward compatibility could be guaranteed between a newer release and a patch release in the case that both included the same Data Serialization change.

Example:
Imagine that 1.13.0 includes a change that adds a new field to a DataSerializable class. In order to support backward compatibility, the change will include the implementation of the corresponding fromDataPre_1_13_0 and toDataPre_1_13_0 methods.

Now, let's assume that this change is decided to be backported to previous patch releases, for example 1.12.0.1. The cherry-picked commit will need to be changed so that the above methods are renamed to fromDataPre_1_12_0_1 and toDataPre_1_12_0_1.

Problems could arise nevertheless when a Geode system on version 1.12.0.1 (patch release) is upgraded to 1.13.0. Both Geode versions will think that the new field was added in their version. As a result, when a peer on version 1.13.0 sends an instance of the modified class to a peer on version 1.12.0.1, it will not send the new field but, the peer on version 1.12.0.1 will expect it. If, on the other hand, a peer on version 1.12.0.1 sends an instance of the modified class to a peer on version 1.13.0, the peer on version 1.13.0 will not read the new field even if it was sent by the peer on 1.12.0.1.

Is there anything I am missing in my reasoning?
Has this case been contemplated?
Should these changes be prevented from support branches to avoid these problems?

Thanks in advance,

-Alberto G.

Re: Questions about patch releases and changes in serialization versions / messages

[Alberto Gomez <al...@est.tech>]

Thanks for the quick answer, Owen.

Is this information published anywhere?

Cheers,

-Alberto G.
________________________________
From: Owen Nichols <on...@pivotal.io>
Sent: Friday, May 22, 2020 5:56 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Questions about patch releases and changes in serialization versions / messages

Serialization changes are only permitted in new minor releases (x.y.0).

> On May 22, 2020, at 4:40 AM, Alberto Gomez <al...@est.tech> wrote:
>
> Hi,
>
> The recently approved RFC about patch releases (https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases) says the following about what changes should and should not be backported to a support branch:
>
> What changes should be back ported to a support branch?
>
> The community will exercise good judgement in the same way that important changes are cherry-picked onto release branches prior to shipping a new release.  Fixes related to data safety and consistency, cluster stability, or API behaviors are good candidates to be considered.
>
> What changes should NOT be back ported to a support branch?
>
> New features, refactoring changes, or less important and non-critical bug fixes.  Of course, you are always free to advocate within the community and state your case!
>
> This raises a question on whether changes that fall on the first category according to the above guidelines but also contain, changes in Data Serialization (for example adding/removing fields from a DataSerializable class) would still be allowed to be backported to a support branch.
>
> If the answer is affirmative, I wonder if/how the backward compatibility could be guaranteed between a newer release and a patch release in the case that both included the same Data Serialization change.
>
> Example:
> Imagine that 1.13.0 includes a change that adds a new field to a DataSerializable class. In order to support backward compatibility, the change will include the implementation of the corresponding fromDataPre_1_13_0 and toDataPre_1_13_0 methods.
>
> Now, let's assume that this change is decided to be backported to previous patch releases, for example 1.12.0.1. The cherry-picked commit will need to be changed so that the above methods are renamed to fromDataPre_1_12_0_1 and toDataPre_1_12_0_1.
>
> Problems could arise nevertheless when a Geode system on version 1.12.0.1 (patch release) is upgraded to 1.13.0. Both Geode versions will think that the new field was added in their version. As a result, when a peer on version 1.13.0 sends an instance of the modified class to a peer on version 1.12.0.1, it will not send the new field but, the peer on version 1.12.0.1 will expect it. If, on the other hand, a peer on version 1.12.0.1 sends an instance of the modified class to a peer on version 1.13.0, the peer on version 1.13.0 will not read the new field even if it was sent by the peer on 1.12.0.1.
>
> Is there anything I am missing in my reasoning?
> Has this case been contemplated?
> Should these changes be prevented from support branches to avoid these problems?
>
> Thanks in advance,
>
> -Alberto G.

Re: Questions about patch releases and changes in serialization versions / messages

[Owen Nichols <on...@pivotal.io>]

Serialization changes are only permitted in new minor releases (x.y.0).  

> On May 22, 2020, at 4:40 AM, Alberto Gomez <al...@est.tech> wrote:
> 
> Hi,
> 
> The recently approved RFC about patch releases (https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases) says the following about what changes should and should not be backported to a support branch:
> 
> What changes should be back ported to a support branch?
> 
> The community will exercise good judgement in the same way that important changes are cherry-picked onto release branches prior to shipping a new release.  Fixes related to data safety and consistency, cluster stability, or API behaviors are good candidates to be considered.
> 
> What changes should NOT be back ported to a support branch?
> 
> New features, refactoring changes, or less important and non-critical bug fixes.  Of course, you are always free to advocate within the community and state your case!
> 
> This raises a question on whether changes that fall on the first category according to the above guidelines but also contain, changes in Data Serialization (for example adding/removing fields from a DataSerializable class) would still be allowed to be backported to a support branch.
> 
> If the answer is affirmative, I wonder if/how the backward compatibility could be guaranteed between a newer release and a patch release in the case that both included the same Data Serialization change.
> 
> Example:
> Imagine that 1.13.0 includes a change that adds a new field to a DataSerializable class. In order to support backward compatibility, the change will include the implementation of the corresponding fromDataPre_1_13_0 and toDataPre_1_13_0 methods.
> 
> Now, let's assume that this change is decided to be backported to previous patch releases, for example 1.12.0.1. The cherry-picked commit will need to be changed so that the above methods are renamed to fromDataPre_1_12_0_1 and toDataPre_1_12_0_1.
> 
> Problems could arise nevertheless when a Geode system on version 1.12.0.1 (patch release) is upgraded to 1.13.0. Both Geode versions will think that the new field was added in their version. As a result, when a peer on version 1.13.0 sends an instance of the modified class to a peer on version 1.12.0.1, it will not send the new field but, the peer on version 1.12.0.1 will expect it. If, on the other hand, a peer on version 1.12.0.1 sends an instance of the modified class to a peer on version 1.13.0, the peer on version 1.13.0 will not read the new field even if it was sent by the peer on 1.12.0.1.
> 
> Is there anything I am missing in my reasoning?
> Has this case been contemplated?
> Should these changes be prevented from support branches to avoid these problems?
> 
> Thanks in advance,
> 
> -Alberto G.