SOLR-18383: remove CollectionParams.FROM_NODE

[serhiy-bzhezytskyy]

https://issues.apache.org/jira/browse/SOLR-18383

Removes CollectionParams.FROM_NODE, deprecated since 10.0 in favor of SOURCE_NODE. 4 sites (constant + its 2 usages in MoveReplicaCmd/CollectionsHandler + the v2 mapping already gone). 0 remaining references anywhere; no dedicated test existed for the legacy alias.

2 tests, 0 failures (MoveReplicaTest, sanity check on MoveReplicaCmd).

SOLR-18370 (local, not yet a PR) also touches CollectionsHandler.java and CollectionParams.java -- re-check once it opens a PR.

AI-assisted (Claude Sonnet 5)

[epugh]

I wonder if this needs anything in the upgrade notes, or did we cover it already. or, is it only used by internal code and so we can freely remove it... Is MoveReplica exposed in Solr Admin UI?

[serhiy-bzhezytskyy]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

[epugh]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

I think I've come around to this is small enough chagne from a public perspective, we don't need to sweat it...

[serhiy-bzhezytskyy]

https://issues.apache.org/jira/browse/SOLR-18383

Removes CollectionParams.FROM_NODE, deprecated since 10.0 in favor of SOURCE_NODE. 4 sites (constant + its 2 usages in MoveReplicaCmd/CollectionsHandler + the v2 mapping already gone). 0 remaining references anywhere; no dedicated test existed for the legacy alias.

2 tests, 0 failures (MoveReplicaTest, sanity check on MoveReplicaCmd).

SOLR-18370 (local, not yet a PR) also touches CollectionsHandler.java and CollectionParams.java -- re-check once it opens a PR.

AI-assisted (Claude Sonnet 5)

[epugh]

I wonder if this needs anything in the upgrade notes, or did we cover it already. or, is it only used by internal code and so we can freely remove it... Is MoveReplica exposed in Solr Admin UI?

[serhiy-bzhezytskyy]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

[epugh]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

I think I've come around to this is small enough chagne from a public perspective, we don't need to sweat it...

[serhiy-bzhezytskyy]

https://issues.apache.org/jira/browse/SOLR-18383

Removes CollectionParams.FROM_NODE, deprecated since 10.0 in favor of SOURCE_NODE. 4 sites (constant + its 2 usages in MoveReplicaCmd/CollectionsHandler + the v2 mapping already gone). 0 remaining references anywhere; no dedicated test existed for the legacy alias.

2 tests, 0 failures (MoveReplicaTest, sanity check on MoveReplicaCmd).

SOLR-18370 (local, not yet a PR) also touches CollectionsHandler.java and CollectionParams.java -- re-check once it opens a PR.

AI-assisted (Claude Sonnet 5)

[epugh]

I wonder if this needs anything in the upgrade notes, or did we cover it already. or, is it only used by internal code and so we can freely remove it... Is MoveReplica exposed in Solr Admin UI?

[serhiy-bzhezytskyy]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

[epugh]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

I think I've come around to this is small enough chagne from a public perspective, we don't need to sweat it...

[serhiy-bzhezytskyy]

https://issues.apache.org/jira/browse/SOLR-18383

Removes CollectionParams.FROM_NODE, deprecated since 10.0 in favor of SOURCE_NODE. 4 sites (constant + its 2 usages in MoveReplicaCmd/CollectionsHandler + the v2 mapping already gone). 0 remaining references anywhere; no dedicated test existed for the legacy alias.

2 tests, 0 failures (MoveReplicaTest, sanity check on MoveReplicaCmd).

SOLR-18370 (local, not yet a PR) also touches CollectionsHandler.java and CollectionParams.java -- re-check once it opens a PR.

AI-assisted (Claude Sonnet 5)

[epugh]

I wonder if this needs anything in the upgrade notes, or did we cover it already. or, is it only used by internal code and so we can freely remove it... Is MoveReplica exposed in Solr Admin UI?

[serhiy-bzhezytskyy]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

[epugh]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

I think I've come around to this is small enough chagne from a public perspective, we don't need to sweat it...

[serhiy-bzhezytskyy]

https://issues.apache.org/jira/browse/SOLR-18383

Removes CollectionParams.FROM_NODE, deprecated since 10.0 in favor of SOURCE_NODE. 4 sites (constant + its 2 usages in MoveReplicaCmd/CollectionsHandler + the v2 mapping already gone). 0 remaining references anywhere; no dedicated test existed for the legacy alias.

2 tests, 0 failures (MoveReplicaTest, sanity check on MoveReplicaCmd).

SOLR-18370 (local, not yet a PR) also touches CollectionsHandler.java and CollectionParams.java -- re-check once it opens a PR.

AI-assisted (Claude Sonnet 5)

[epugh]

I wonder if this needs anything in the upgrade notes, or did we cover it already. or, is it only used by internal code and so we can freely remove it... Is MoveReplica exposed in Solr Admin UI?

[serhiy-bzhezytskyy]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

[epugh]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

I think I've come around to this is small enough chagne from a public perspective, we don't need to sweat it...

[serhiy-bzhezytskyy]

https://issues.apache.org/jira/browse/SOLR-18383

Removes CollectionParams.FROM_NODE, deprecated since 10.0 in favor of SOURCE_NODE. 4 sites (constant + its 2 usages in MoveReplicaCmd/CollectionsHandler + the v2 mapping already gone). 0 remaining references anywhere; no dedicated test existed for the legacy alias.

2 tests, 0 failures (MoveReplicaTest, sanity check on MoveReplicaCmd).

SOLR-18370 (local, not yet a PR) also touches CollectionsHandler.java and CollectionParams.java -- re-check once it opens a PR.

AI-assisted (Claude Sonnet 5)

[epugh]

I wonder if this needs anything in the upgrade notes, or did we cover it already. or, is it only used by internal code and so we can freely remove it... Is MoveReplica exposed in Solr Admin UI?

[serhiy-bzhezytskyy]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

[epugh]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

I think I've come around to this is small enough chagne from a public perspective, we don't need to sweat it...

[serhiy-bzhezytskyy]

https://issues.apache.org/jira/browse/SOLR-18383

Removes CollectionParams.FROM_NODE, deprecated since 10.0 in favor of SOURCE_NODE. 4 sites (constant + its 2 usages in MoveReplicaCmd/CollectionsHandler + the v2 mapping already gone). 0 remaining references anywhere; no dedicated test existed for the legacy alias.

2 tests, 0 failures (MoveReplicaTest, sanity check on MoveReplicaCmd).

SOLR-18370 (local, not yet a PR) also touches CollectionsHandler.java and CollectionParams.java -- re-check once it opens a PR.

AI-assisted (Claude Sonnet 5)

[epugh]

I wonder if this needs anything in the upgrade notes, or did we cover it already. or, is it only used by internal code and so we can freely remove it... Is MoveReplica exposed in Solr Admin UI?

[serhiy-bzhezytskyy]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

[epugh]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

I think I've come around to this is small enough chagne from a public perspective, we don't need to sweat it...

[serhiy-bzhezytskyy]

https://issues.apache.org/jira/browse/SOLR-18383

Removes CollectionParams.FROM_NODE, deprecated since 10.0 in favor of SOURCE_NODE. 4 sites (constant + its 2 usages in MoveReplicaCmd/CollectionsHandler + the v2 mapping already gone). 0 remaining references anywhere; no dedicated test existed for the legacy alias.

2 tests, 0 failures (MoveReplicaTest, sanity check on MoveReplicaCmd).

SOLR-18370 (local, not yet a PR) also touches CollectionsHandler.java and CollectionParams.java -- re-check once it opens a PR.

AI-assisted (Claude Sonnet 5)

[epugh]

I wonder if this needs anything in the upgrade notes, or did we cover it already. or, is it only used by internal code and so we can freely remove it... Is MoveReplica exposed in Solr Admin UI?

[serhiy-bzhezytskyy]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

[epugh]

Checked all three:

• fromNode is a public REST param for MOVEREPLICA (read directly from the request in MoveReplicaCmd), not internal-only.
• MoveReplica isn't exposed in either the classic or the new experimental Admin UI (checked both, zero hits) -- no UI code to update.
• There's precedent for exactly this: major-changes-in-solr-10.adoc has a "Deprecation Code Removals" section listing single-param/field-type removals of similar or smaller scope (EnumField, CurrencyField, addHttpRequestToContext).

Given that, this whole batch is probably under-documented -- going through the other tickets, at least 9-11 more removals look similarly upgrade-notes-worthy (CloudSolrClient.connect()/the legacy Builder in particular -- likely the biggest compile-break in the batch). Before I add a "Deprecation Code Removals" section to major-changes-in-solr-11.adoc covering the whole batch, @dsmiley@epugh -- does that match what you'd want documented, or is there a narrower bar you'd prefer (e.g. skip aliases like PROPERTY_PREFIX that never had real behavior of their own)?

AI-assisted (Claude Sonnet 5)

I think I've come around to this is small enough chagne from a public perspective, we don't need to sweat it...