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