Still in beta stage - please suggest improvemets to the process/wording.
This page describes a proposed Solr Improvement Proposal (SIP) process for proposing a major change to Solr.
...
This process also isn't meant to discourage incompatible changes — proposing an incompatible change is totally legitimate. Sometimes we will have made a mistake and the best path forward is a clean break that cleans things up and gives us a good foundation going forward. Rather this is intended to avoid accidentally introducing half thought-out interfaces and protocols that cause needless heartburn when changed. Likewise the definition of "compatible" is itself squishy: small details like which errors are thrown when are clearly part of the contract but may need to change in some circumstances, likewise performance isn't part of the public contract but dramatic changes may break use cases. So we just need to use good judgement about how big the impact of an incompatibility will be and how big the payoff is.
Please expand and read the section below for more details about the SIP process.
Expand |
---|
What is considered a "major change" that needs a SIP?Any of the following should be considered a major change: - Any major new feature, subsystem, or piece of functionality
- Any change that impacts the public interfaces of the project
What are the "public interfaces" of the project?
All of the following are public interfaces that people build around: - All interfaces published for plugin authors (QParser, UpdateProcessor, ResponseWriter, SearchComponent etc)
- On-disk binary formats, such as index and backup structure
- User-facing scripts/command-line tools, i.e. bin/solr
- Layout of Zookeeper (i.e. location of configsets)
- Format of important ZK nodes
- Configuration files (such as schema.xml, solrconfig.xml, security.json, clusterprops.json)
- Exposed monitoring information
Not all compatibility commitments are the same. We need to spend significantly more time on public APIs as these can break code for users. They cause people to rebuild code and lead to compatibility issues in large multi-dependency projects (which end up requiring multiple incompatible versions). Configuration, monitoring, and command line tools can be faster and looser — changes here will break monitoring dashboards and require a bit of care during upgrades but aren't a huge burden. For the most part monitoring, command line tool changes, and configs are added with new features so these can be done with a single SIP. What should be included in a SIP?A SIP should contain the following sections: - Motivation: describe the problem to be solved
- Proposed Change: describe the new thing you want to do. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences, depending on the scope of the change.
- New or Changed Public Interfaces: impact to any of the "compatibility commitments" described above. We want to call these out in particular so everyone thinks about them.
- Migration Plan and Compatibility: if this feature requires additional support for a no-downtime upgrade describe how that will work
- Performance impact: How will the change affect performance? Benchmarking
- Rejected Alternatives: What are the other alternatives you considered and why are they worse? The goal of this section is to help people understand why this is the best solution now, and also to prevent churn in the future when old alternatives are reconsidered.
Who should initiate the SIP?Anyone can initiate a SIP but you shouldn't do it unless you have an intention of getting the work done to implement it (otherwise it is silly). ProcessHere is the process for making a SIP: - If you don't have the necessary permissions for creating a new page, please ask on the development mailing list.
- Create a page which is a child of this one. Take the next available SIP number and give your proposal a descriptive heading. e.g. "SIP 42: Solr API v3".
- Fill in the sections as described above
- Start a [DISCUSS] thread on the mailing list. Please ensure that the subject of the thread is of the format [DISCUSS] SIP-{your SIP number} {your SIP heading}. Discussion can also happen on the WIKI page for the SIP by using Confluence inline commenting system (Mark the words you want to comment and clik the comment icon that pops up).
|
...
- When feedback iteration trails off on the DISCUSS thread, move to either adopt the proposal. To do this you can either:
- rely on lazy consensus - announce your intention to proceed with the SIP as written unless there are any further objections, then wait 3 business days for readers to object or request an explicit VOTE instead.
- Alternatively, you can jump right to calling a formal VOTE. Create a VOTE thread that points readers to your proposal and ask for votes. The criteria for acceptance is consensus (3 binding +1 votes and no binding vetoes)
|
...
- . Once a VOTE thread is created, add a link to the table below so the outcome can be tracked clearly.
- If the proposal was accepted, move the SIP from the "Under Discussion" table to the "Adopted" table below. If the proposal failed to pass, move the SIP to the "Discarded" table.
- Implement the SIP.
- When implementation is complete, move the SIP to the "Implemented" table below
|
...
SIP round-up
Next SIP Next SIP Number: 922
Use this number as the identifier for your SIP and increment this value.
SIPs under discussion
SIP | State | Link to JIRA | Link to dev@ Discussion Thread |
---|
SIP-1: Streamline Config/Schema APIs | Discuss | Jira |
---|
server | ASF JIRA |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-14041 |
---|
|
|
|
SIP-2 Support safe index transformations without reindexing | Discuss | Jira |
---|
server | ASF JIRA |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-14116 |
---|
|
|
|
SIP-3 Solr-specific log and thread indexing and UI | Discuss | Jira |
---|
server | ASF JIRA |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-14121 |
---|
|
|
|
SIP-4 Resource management framework | Discuss | Jira |
---|
server | ASF JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-13579 |
---|
|
Jira |
---|
server | ASF JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-13578 |
---|
|
|
|
SIP-5 Coordination Module + Apache Curator | Discuss |
|
|
SIP-6 Solr should own the bootstrap process | Discuss | Jira |
---|
server | ASF JIRA |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-14361 |
---|
|
| Mail thread |
SIP-7 Updated Solr Admin UI | Discuss | Jira |
---|
server | ASF JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
|
|
SIP-8 Autoscaling policy engine V2 | Mail thread |
SIP-9 Advanced Query Parser | Discuss | Jira |
---|
server | ASF JIRA |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-14597 |
---|
|
| Mail thread |
SIP-11 Uniform cluster-level configuration API | Discuss | Jira |
---|
server | ASF JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR- |
---|
|
|
14275 | Slack thread |
SIP-14 Embedded Zookeeper | Discuss | Jira |
---|
server | ASF JIRA |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-15636 |
---|
|
| Mail thread |
SIP-16 Polish and Prepare v2 APIs for v1 deprecation | Discuss | SOLR-15734 |
|
SIP-19 Adopt JSR-330 dependency injection | Discuss | Jira |
---|
server | ASF JIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-16998 |
---|
|
| Mail thread |
SIP-20: Separation of Compute and Storage in SolrCloud | Discuss | |
|
SIP-21: Standardize system property naming | Discuss | Jira |
---|
server | ASF JIRA |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-17111 |
---|
|
| Mail |
Slack
Adopted/Accepted but unreleased SIPs
Implemented and Released SIPs
SIP | First Release Version | Link to JIRA | Link to dev@ Discussion Thread |
---|
SIP-8 Autoscaling policy engine V2 | Discuss | Jira |
---|
server | ASF JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-14275 |
---|
|
| Slack thread |
SIP-15 Node roles | 9.0 | Jira |
---|
server | ASF JIRA |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-15694 |
---|
|
| Mail thread
|
SIP-12 Incremental Backup and Restore | 8.9 | Jira |
---|
server | ASF JIRA |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-15086 |
---|
|
| Mail thread |
SIP-17: Node Autoscaling via Kubernetes | Solr 9.3 Solr Operator v0.8.0 | Jira |
---|
server | ASF JIRA |
---|
columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | SOLR-16727 |
---|
| Solr Operator Issue #536 | Mail thread |
Discarded SIPs