Page History

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).

Process

Here is the process for making a SIP:

1. If you don't have the necessary permissions for creating a new page, please ask on the development mailing list.
2. 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".
3. Fill in the sections as described above
4. 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).
5. When feedback iteration trails off on the DISCUSS thread, move to either adopt the proposal.  To do this you can either:
   1. 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.
   2. 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.
6. 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.
7. Implement the SIP.
8. When implementation is complete, move the SIP to the "Implemented" table below.