...

• Be an advocate for the proposed change
• Ensure the working group achieves consensus among key stakeholders
• Ensure the working group seeks feedback from users and iterates on the design & implementation (see below for additional CEP documentation)
• Uphold the quality of the changes, including verifying whether the changes satisfy the goal of the CEP and are absent of critical bugs before releasing them
• Be committed to review code changes, ensuring project standards

What is considered a "major change" that needs a CEP?

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 (see below)

The Process

Here is the process for making a CEP:

...

• Motivation: The problem to be solved.
• Audience: The intended client audience. Examples include data scientists, data engineers, library devs, devops, etc. A single CEP can have multiple target personas. 
  
• Proposed Change: 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.
• 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.

Cassandra's Public Interfaces

Not all compatibility commitments are the same. We need to spend significantly more time on the wire protocols as these break code in lots of clients, cause downtime releases, etc. Public API/SPIs are next as they cause people to rebuild code and/or maintain abstraction layers in third-party libraries/frameworks. 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 as big a 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 CEP.

Compatibility Concerns

Cassandra requires a high level of compatibility between releases , especially to ensure rolling upgrades are possible. Core architectural elements can't break compatibility or shift functionality from release to release. As a result each new major feature or public api has to be done in a way that we can stick with it going forward., as well as supporting third-party libraries and tools.

These areas of compatibility Areas of compatibility, or "public interfaces" to the project, are 

• native protocol (and CQL)
• gossip and the messaging service
• pluggable components (SPIs) like authorisation, triggers, …
• commitlog, hintlog, cache files
• sstables components 
• configuration
• jmx mbeans (including metrics)
• monitoring
• client tool classes
• command line tools and arguments
• operational routines
• …

When making changes or additions that impact these areas 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 flip-flopping needlessly.

...

...

List of CEPs

Adopted CEPs

...