Personally, I would really prefer the Trie fields not be removed entirely. It allows me to reindex in-place without service disruption and without needing additional hardware (even temporarily) since I can continue with the same schema.
Maybe we can leave these as is if they don't contribute to any spurious test failures or have any bugs reported ? aka don't add to any maintenance overhead in their current form. Otherwise I like Hoss's idea of moving such artifacts to a solr-sandbox or a solr-attic and cleaning up the tests in core. - Rahul On Thu, Sep 25, 2025 at 2:46 PM Chris Hostetter <[email protected]> wrote: > : With 10 starting to loom, me and Claude went and looked for code that > could be removed. Here is what we found: > : > https://cwiki.apache.org/confluence/display/SOLR/Solr+10+Deprecation+Removal+Opportunities > > You two are my newest favorite people. > > : I was thinking of teeing up a single JIRA with multiple PR's to work > : through the list, or if we prefer, a JIRA with sub task JIRA's for each > : one? > > I think it really depends on complexity -- a lot of "related" things may > easily be lumped into a single Jira Sub-Task, but some stuff may require > more thought -- especially in terms of how removing it impacts test > coverage of *other* code paths that aren't being removed) and should live > in it's own Sub-Task > > : There is a column "Decision", if you think something Deprecated *SHOULD* > stay in Solr 10, then please speak up! > > I also want to call out something at the top of this jira page... > > > One thing is, we mark things deprecated that we don't actually intend to > > remove, instead we are saying "don't use this". Examples are > > TrieFields. I guess if they don't cost us much in maintence or > > performance issues it's fine... But... I hate things marked deprecated > > that just linger and > don't have clear documentation about WHY they are > > deprecated. > > what about moving some of these "classes you might explicitly refrence in > your config files" type deprecations into solr-sandbox? > > ie: we don't want to maintain them (and their tests) in solr-core, but we > can "snapshot" them and put them in solr-sandbox and if you really don't > want to upgrade your configs (or re-index) you can go add some > "solr-deprecated-core-plugins" module from the sandbox > > ? > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
