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.
