I'd prefer to see Trie fields hang out a bit longer. These fields are proper plugins (i.e. they subclass types), so their presence is relatively minor for their project maintenance impact.
On Fri, Sep 26, 2025 at 12:10 AM Rahul Goswami <[email protected]> wrote: > 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] >
