Since we want to be bending our energies towards Solr 10, I think if heroics are required for 9 then it’s okay to not back port.
Sent from my iPhone > On Sep 20, 2025, at 2:03 PM, Christos Malliaridis <[email protected]> > wrote: > > It doesn't need to be backported. It was only a question of "if we want > this update, we should make sure this is not a breaking change". Since I > don't know if that may break something, or if the deserization still works > with the previously serialized data, I thought I just ask for some > reviewers that know better. > > Worst that could happen is that we don't get that dependency update in 9x. > >> On Tue, Sep 16, 2025 at 12:28 AM Ishan Chattopadhyaya < >> [email protected]> wrote: >> >> Can we make the change only for Solr 10, where breaking changes are >> acceptable? >> Or, does it need to be in 9x? >> >> >> On Tue, 16 Sept 2025 at 02:06, Christos Malliaridis < >> [email protected]> >> wrote: >> >>> Hello everyone, >>> >>> I am seeking advice for a potential breaking change that I may introduce >>> with backporting the FasterXML version update (from 2.18.0 to 2.20.0). >>> >>> The new version improves (as far as I understand the changelogs) the >>> efficiency of the CBOR serialization, leading to smaller serialized >>> objects. I believe that is the reason why the test (see backport PR >> commit >>> [1]) was failing and had to be updated. >>> >>> However, I cannot estimate the impact of this change. I am not sure if >> the >>> different byte size could break compatibility with any existing >>> (serialized) data during an update (if the test checks the byte size >> there >>> is likely a reason). I believe there is no risk of backporting, but I >>> wanted to be sure before merging the version update to 9x. >>> >>> Best, >>> Christos >>> >>> [1] >>> >>> >> https://github.com/apache/solr/pull/3536/commits/5e0210a180f1aac5b3086a69735d60409e12dabd >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
