Page History

...

This means when making this kind of change we need to think through what we are doing as best we can prior to release. And as we go forward we need to stick to our decisions as much as possible. All technical decisions have pros and cons so it is important we capture the thought process that lead to a decision or design to avoid SIP-flopping needlessly.

Hopefully we can make these proportional in effort to their magnitude — small changes should just need a couple brief paragraphs, whereas large changes need detailed design discussions.

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.

...

1. 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". If you don't have the necessary permissions for creating a new page, please ask on the development mailing list.
2. Fill in the sections as described above
3. 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} The discussion should . Discussion can also happen on the mailing list not on the wiki since the wiki comment system doesn't work well for larger discussions. In the process of the discussion you may update the proposal. You should let people know the changes you are makingWIKI 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).
4. Once the proposal is finalized call a [VOTE] to have the proposal adopted. These proposals are more serious than ordinary code changes and more serious even than release votes. The criteria for acceptance is consensus (3 binding +1 votes and no binding vetoes).
5. Please update the SIP wiki page, and the index below, to reflect the current stage of the SIP after a vote. This acts as the permanent record indicating the result of the SIP (e.g., Accepted or Rejected). Also report the result of the SIP vote to the voting thread on the mailing list so the conclusion is clear.

SIP round-up

Next SIP Number: 21

Use this number as the identifier for your SIP and increment this value.

SIPs under discussion

Adopted/Accepted but unreleased SIPs

...