In that case I will move forward and close the PR. In case someone can
confirm that this is not a breaking change and the PR should be backported,
they can reopen the PR and merge the changes.

Link to the PR: https://github.com/apache/solr/pull/3536/

Thanks for your inputs all,
Christos

On Mon, 22 Sep 2025, 13:45 Eric Pugh, <[email protected]> wrote:

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

Reply via email to