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 > > >
