This page details the current plans for future releases, these plans may change from time to time so check back regularly.

It is not a goal to list all Jira issues in a release here. Only major & controversial features, deprecations, breaking changes and other tasks that need coordination between releases need an entry.

Deprecations

They are listed here separately on this page: Deprecations

Future possibilities

Not started; may need discussion

  • OpenTelemetry for Metrics instead of DropWizard.  Attribute based; supports pushing metrics thus avoiding Prometheus translation
  • Segment level filterCache, augmenting or replacing current global strategy
  • Limit concurrent HTTP requests / threads to a sane value, not 10k in jetty.xml.  Not trivial; don't want to dead-lock at scale.  Related (but not the same) issue: SOLR-7344 - Getting issue details... STATUS
  • schema.xml:  Default field types (esp. for non-text) so users needn't define the basics.
  • Transition from "javabin" to CBOR via Jackson.  Status of CBOR – SOLR-17510 - Getting issue details... STATUS
  • Load built-in and other plugins via Java java.util.ServiceLoader / SPI, just like how Lucene components are loaded.
  • NamedList: move away from this in configuration. dev thread, and this dev thread RE ConfigurablePlugin
    • Initial baby step: root NamedLists to any plugin config should be a SimpleOrderedMap.  And enforce uniqueness
  • CHANGES.txt generation / management.   SOLR-17619 - Getting issue details... STATUS

Roadmap

Started but not finished

SolrCloud

  • Distributed State Updates (vs Overseer) SOLR-14927 - Getting issue details... STATUS
    • Status 2024-04:  real-world usage required to push this further.  Concerned about large collection (many-replica) performance; maybe PRS addresses this?  Or maybe not worth worrying about too much.
  • PRS: should Solr just work this way, removing the non-PRS code path? SOLR-17270 - Getting issue details... STATUS
    • Status 2024-04:  Finally, tests randomly choose PRS

HTTP "V2 API", redux: OpenAPI / JAX-RS / Jersey.  SIP-16 and see SOLR-15734 - Getting issue details... STATUS with many child JIRAs that also have child JIRAs

  • V2 API (old or new): complete coverage SOLR-15737 - Getting issue details... STATUS
  • OpenAPI / JAX-RS: complete coverage  (thus remove old way)

HttpClient transition from Apache to Jetty (Solr & SolrJ) and thus HTTP2 SOLR-16367 - Getting issue details... STATUS

  • solr server shouldn't depend on Apache HttpClient.  Tests will lag behind though.
  • solrj-core shouldn't depend on Apache HttpClient.  Could be an optional module.
  • modularize solrj HttpClient of both Jetty & Apache clients (to separate modules)
    • likely requires a CloudSolrClient using JDK HttpClient

SolrJ / demote solrj-zookeeper (use HTTP Solr URLs for CloudSolrClient) – SOLR-17605 - Getting issue details... STATUS  dev-list thread

  • End-state is to merge solrj-zookeeper into solr-core.
  • End-state: most of Solr's tests that call waitForState after collection creation can finally stop doing so
  • ClusterStateProvider and CloudSolrClient may need some love.
    • performance issues are fixed already (9.8)
    • deficiency if all Solr nodes go down; easy fix
    • assumptions about ClusterState; API issues
  • Prometheus Exporter should use it.

Package Manager

  • First Party Packages:  status: needs a SIP (proposal/design) – SOLR-14688 - Getting issue details... STATUS also see linked items, some with PRs

Solr Admin UI revamp – SIP-7 Updated Solr Admin UI

Testing (solr-test-framework) SOLR-11872 - Getting issue details... STATUS

  • Ideal base class should be SolrTestCase, not SolrTestCaseJ4; latter should be deprecated.  Status:  STCJ4 still has some functionality that should migrate to STC or elsewhere.
  • Ideal tests of Solr use SolrClient, not TestHarness.  TestHarness needs to be deprecated; it's used extensively in STCJ4.  Some test utilities like assertQ need SolrClient compatible replacements.  SolrClient should ideally be obtained by using an appropriate SolrClientTestRule.  SolrClientTestRule needs a SolrCloud variant.
  • Ideal tests strongly avoid creating new configuration files.  Need more/better configuration utilities to make config setup easier and more standardized.
  • Need test docs to make best-practice findable.

Solr 9x

ItemDescriptionContributorsThemeJira
HTTP 1 → HTTP 2 Switch the remaining HTTP 1 usage within Solr to HTTP 2.  Apache HttpClient should no longer be used on the server.Smiley

Modularize SolrJSolrJ should be lighter-weight (smaller) for more users; fewer dependencies.  Add modules for some dependencies and functionality.Smiley, Jan, Houston, others

Use JAX-RSJAX-RS based V2 API definitions; use more and more.  Jason

Solr 9.0

The theme of this release is to use Lucene 9.0 and to introduce some major frameworks.

We should not remove all features/APIs deprecated in 8.x yet, to give users a path to upgrade to 9.x without all the extra noise. Deprecated features can be removed in a later 9.x release, when the new alternative is solid and well known.

ItemDescriptionContributorsThemeJira
First party packages & Slim Solr distributionSolr should have first party packages, and a slim Solr tarball that doesn't have the first party packagesIshan, Noble, Jan, et. al.Lean Solr Core

SOLR-14688 - Getting issue details... STATUS

V2 API to be the defaultRef guide docs should use V2, where necessary we build V2 APIs, switch SolrJ to use V2 APIs, etc.
Usability
Autoscaling / Replica assignment V2

A new pluggable framework replaces current autoscaling


Andrzej, Ilan, NobleLean Solr Core
SOLR-14749 - Getting issue details... STATUS

SOLR-14613 - Getting issue details... STATUS

HDFS moved away from Solr-CoreBuild a first party package out of HDFS supportIstvan Farkas, GezapetiLean Solr Core
Remove Ant support



Tech-debt

LUCENE-9433 - Getting issue details... STATUS

Index Lifecycle ManagementAutomatically move indices between hot, warm and cold phasesAtri SharmaFeature
POJOs instead of loosely typed objectsStart using POJOs/interfaces wherever possible in public APIs where ever possibleNoble Paul

Remove Filter.java from SolrFilter.java is a legacy relic from earlier Lucene days.  Solr uses Filter in a variety of places where it can use other constructs or in some cases we need to make new constructs.  In some cases like TwoPhaseIterator, this is an optimization.David SmileyTech-debt

SOLR-12336 - Getting issue details... STATUS

Solr 8.9

Last version before 9.0?

ItemDescriptionContributorsThemeJira
Alternate SolrJ APIs without using NamedList/SimpleOrderedMap/MapGet rid of concrete classes such as NamedList,SimpleOrderedMap, Map, etc and build our public APIs with interfacesNoble PaulClean-API

SOLR-14730 - Getting issue details... STATUS

New Cluster APIStandard set of APIs which consists of only interfaces. We should ensure that They are used wherever possible in server/client code. We should expose these interfaces to our plugins. They should be well -documented and we must always strive to maintain backward compatibility on these interfaces between versionsNoble PaulClean-API

SOLR-14680 - Getting issue details... STATUS

New Remote Call APIRemote Calls should have simple constructs and they must be public interfaces. This should be used in all inter-node/client-server communicationsNoble PaulClean-API

SOLR-14712 - Getting issue details... STATUS

Multi-threaded search (SOLR-13350)

Multi threaded search across multiple segments at once, using CollectorManagers


Ishan Chattopadhyaya, Atri SharmaOptimization

SOLR-13350 - Getting issue details... STATUS

SIP-9

Advanced Query parser and supporting lucene filters


Mike Nibeck (LOC contributor), Gus HeckFeature

SOLR-14597 - Getting issue details... STATUS







  • No labels