Thanks for the quick answer, Owen. Is this information published anywhere?
Cheers, -Alberto G. ________________________________ From: Owen Nichols <onich...@pivotal.io> Sent: Friday, May 22, 2020 5:56 PM To: dev@geode.apache.org <dev@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 <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.