LUCENE-10236: Update field-weight used in CombinedFieldQuery scoring calculation (9.1.0 Backporting)

[zacharymorn]

This PR backports bug fix #444 to version 9.1.0

[jpountz]

Feel free to merge this if tests pass and you didn't have to make significant changes upon backporting. Do we also need to move the CHANGES entry to a different version on other branches?

[zacharymorn]

Feel free to merge this if tests pass and you didn't have to make significant changes upon backporting. Do we also need to move the CHANGES entry to a different version on other branches?

Thanks @jpountz ! Yes the 3 backports / cherry-pick did not incur any merge conflict and tests passed on them. For the CHANGES entry, I did have it under different versions for different PRs / branches, or do you think that's not needed?

[jpountz]

For the CHANGES entry, I did have it under different versions for different PRs / branches, or do you think that's not needed?

The CHANGES file is supposed to have a JIRA issue under the earlier version that has this change. For instance if you merge something today that gets backported to 9.1, it should be added to the 9.1 section of the CHANGES entry.

[zacharymorn]

The CHANGES file is supposed to have a JIRA issue under the earlier version that has this change. For instance if you merge something today that gets backported to 9.1, it should be added to the 9.1 section of the CHANGES entry.

I think I did this already. This PR has the change entry under 9.1.0 section, #587 has it under 9.0.1, and apache/lucene-solr#2637 has it under 8.11.2 ?

[jtibshirani]

@zacharymorn here's my understanding of our usual strategy: on every branch of the same major release, the change always appears under the same release (like 9.1.0), corresponding to the earliest release that contains the change.

In addition, I'm not sure we preemptively backport changes unless we think they'll be released. For example, it's not clear we'll have a 9.0.1 or 8.11.2 release. If we did decide to have one, we could backport the change at that point and move the changelog entries. (But I do see some existing changelog entries for 9.0.1, hmm, maybe others are planning something).

Maybe we can keep it simple with this change and just backport to branch_9x, and the changelog entry would be 9.1.0 everywhere?

[zacharymorn]

Thanks @jtibshirani for the suggestions here! I have a few follow-up questions:

@zacharymorn here's my understanding of our usual strategy: on every branch of the same major release, the change always appears under the same release (like 9.1.0), corresponding to the earliest release that contains the change.

Maybe we can keep it simple with this change and just backport to branch_9x, and the changelog entry would be 9.1.0 everywhere?

I think my main reasoning here is that since this change is a bug fix, it should ideally go to branch_9_0 first for the next / first bug patch release for version 9. In addition, since branch branch_9x was already cut for 9.1.x and onward, this fix should be backported to branch_9x as well so that future non-9.0.x versions also have it . Maybe the best strategy here would be to keep the change entry for whichever version that goes out first (I think it will be 9.0.1? ), and for the other one we can skip the change entry to avoid duplication?

In addition, I'm not sure we preemptively backport changes unless we think they'll be released. For example, it's not clear we'll have a 9.0.1 or 8.11.2 release. If we did decide to have one, we could backport the change at that point and move the changelog entries. (But I do see some existing changelog entries for 9.0.1, hmm, maybe others are planning something).

I would actually imagine 9.0.1 release to happen soon (and before 9.1.0?) given it is the first bug fix release for version 9. I'm fine with holding off backporting to 8.11.2 if there's no plan for it soon, but not sure what will be the best mechanism to track this delayed backport if 8.11.2 were to be released later on? Shall I mark this as a blocker for 8.11.2 in Jira?

[jtibshirani]

Maybe the best strategy here would be to keep the change entry for whichever version that goes out first (I think it will be 9.0.1? ), and for the other one we can skip the change entry to avoid duplication?

Yep, this seems like the right strategy. There should only be one changelog entry, and it should be the same version in both main and branch_9x.

I would actually imagine 9.0.1 release to happen soon (and before 9.1.0?) given it is the first bug fix release for version 9.

I'm not sure that we'll release 9.0.1, I haven't seen any email message proposing it. From my understanding, we don't always make patch releases if there are bug fixes, often we just jump to the next minor.

I think that most developers just backport to the unstable branches main and branch_9x. Then someone sends an email proposing "I'd like a bugfix release 8.11.2, is there anything you want to add before I cut the branch?" Then people backport fixes before the release.

[zacharymorn]

Maybe the best strategy here would be to keep the change entry for whichever version that goes out first (I think it will be 9.0.1? ), and for the other one we can skip the change entry to avoid duplication?

Yep, this seems like the right strategy. There should only be one changelog entry, and it should be the same version in both main and branch_9x.

I would actually imagine 9.0.1 release to happen soon (and before 9.1.0?) given it is the first bug fix release for version 9.

I'm not sure that we'll release 9.0.1, I haven't seen any email message proposing it. From my understanding, we don't always make patch releases if there are bug fixes, often we just jump to the next minor.

I think that most developers just backport to the unstable branches main and branch_9x. Then someone sends an email proposing "I'd like a bugfix release 8.11.2, is there anything you want to add before I cut the branch?" Then people backport fixes before the release.

I see. Thanks for the detailed explanation @jtibshirani ! I'll only merge this one and hold off on apache/lucene-solr#2637 & #587 for now then.