Serialization changes are only permitted in new minor releases (x.y.0).
> On May 22, 2020, at 4:40 AM, Alberto Gomez <alberto.go...@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.
