Subject: [DISCUSS] Required IEP approval for API, protocol, and storage changes

[Anton Vinogradov <av...@apache.org>]

Hi everyone,

Ignite has a long history of features remaining unfinished in the codebase.

- MVCC
- Tracing API
- Local caches
- H2-to-Calcite migration
- Spark 3 integration
- etc.

We need clear rules for making decisions. We also need clear plans for
completing and supporting features.

Changes that affect future releases need to be reviewed by the community
before they are merged.

I propose the following:

1) An IEP is required before merging any change to:
- Public APIs or their supported behavior.
- Client or internode protocols.
- Data formats stored on disk.

2) Each IEP must explain the plan, what counts as complete, and how the
change affects compatibility and future support.

3) Each IEP must be approved by a vote on the dev list or through a similar
mechanism (perhaps likes on the IEP page). Approval requires at least three
positive votes or likes from Ignite committers.

4) One approved IEP can cover several PRs.

5) Internal changes that keep APIs, protocols, and formats unchanged do not
require an IEP for now. The same applies to bug fixes that restore the
agreed behavior.

WDYT?

Re: Subject: [DISCUSS] Required IEP approval for API, protocol, and storage changes

[Nikolay Izhikov <ni...@apache.org>]

Hello.

Long awaited improvement of the development process.
Heavy +1

пн, 5 окт. 2026 г. в 16:52, Anton Vinogradov <av...@apache.org>:
>
> Hi everyone,
>
> Ignite has a long history of features remaining unfinished in the codebase.
>
> - MVCC
> - Tracing API
> - Local caches
> - H2-to-Calcite migration
> - Spark 3 integration
> - etc.
>
> We need clear rules for making decisions. We also need clear plans for
> completing and supporting features.
>
> Changes that affect future releases need to be reviewed by the community
> before they are merged.
>
> I propose the following:
>
> 1) An IEP is required before merging any change to:
> - Public APIs or their supported behavior.
> - Client or internode protocols.
> - Data formats stored on disk.
>
> 2) Each IEP must explain the plan, what counts as complete, and how the
> change affects compatibility and future support.
>
> 3) Each IEP must be approved by a vote on the dev list or through a similar
> mechanism (perhaps likes on the IEP page). Approval requires at least three
> positive votes or likes from Ignite committers.
>
> 4) One approved IEP can cover several PRs.
>
> 5) Internal changes that keep APIs, protocols, and formats unchanged do not
> require an IEP for now. The same applies to bug fixes that restore the
> agreed behavior.
>
> WDYT?

Re: Subject: [DISCUSS] Required IEP approval for API, protocol, and storage changes

[Nikita Amelchev <na...@apache.org>]

+1 overall.

Could you clarify how API deprecation and removal would be handled?
For example, deprecation could require only a dev-list discussion,
while removal after at least one release could proceed without
additional approval.

On Tue, Oct 6, 2026 at 1:17 PM Nikolay Izhikov <ni...@apache.org> wrote:
>
> Hello, Kirill.
>
> > Don't you think that by introducing a stricter development process, we might increase development time where it isn't necessary?
>
> The point here - we want to improve decisions quality and long term
> API stability.
>
> > 1. You could provide more explanations and examples here.
> > Take `SELECT FOR UPDATE`, for instance, which was introduced recently.
> > As I understand it, since this was a change to the public API, the procedure should have been to create an IEP, go through its full lifecycle, and only then begin implementation?
>
> Yes.
>
> > What should be done if problems are found in the current IEP, or something was overlooked, and it needs to be improved, does that also require a new IEP?
>
> Yes.
>
> The goal of IEP and voting process is to prevent issues in the API.
> So, If we spend more time before pinning API then we will prevent
> future broken changes and complete features removal.
>
> > 2. Who will be responsible for verifying that no backward compatibility cases have been overlooked?
>
> IEP author in the first place.
> Ignite community as an entity that supports project in a healthy state.
>
> > What do you mean by "support"?
> > Who will be responsible for the IEPs and their bug fixes?
>
> Nothing changes here.
> Community is responsible for fixing bugs and improving project.
>
> > 3. And how does it differ from the current mechanism?
>
> 1. By writing down clear rules what MUST be done with the IEP process:
> changes in public API and public behaviour (client, disk formats).
> 2. By enlarging the number of approvals required to change public things.
>
> > Have you seen similar practices in other public projects?
>
> Yes. Many projects has similar approach:
>
> * Kakfa KIPs - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55155994
> * Cassandra CEPs -
> https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/95652201/Cassandra+Enhancement+Proposals+CEP
> * Spark SPIPs - https://spark.apache.org/improvement-proposals.html
> * Pyathon PEPs - https://peps.python.org/
>
> to name a few.
> It is much harder to name a project that allows changing public API
> with the one approval rather than opposite.
>
> вт, 6 окт. 2026 г. в 09:05, Kirill Tkalenko <tk...@yandex.ru>:
> >
> > Hi Anton!
> >
> > I am not in favor of increasing formalism or swinging too far in either direction; doing everything without IEPs, or relying solely on them, both seem concerning at this stage.
> >
> > I would suggest keeping the current approach where major changes or features require an IEP, while small or minor ones can simply be discussed on the dev list.
> >
> > Don't you think that by introducing a stricter development process, we might increase development time where it isn't necessary?
> >
> > Regarding your points:
> >
> > 1. You could provide more explanations and examples here. Take `SELECT FOR UPDATE`, for instance, which was introduced recently. As I understand it, since this was a change to the public API, the procedure should have been to create an IEP, go through its full lifecycle, and only then begin implementation? What should be done if problems are found in the current IEP, or something was overlooked, and it needs to be improved, does that also require a new IEP?
> >
> > 2. Who will be responsible for verifying that no backward compatibility cases have been overlooked? What do you mean by "support"? Who will be responsible for the IEPs and their bug fixes?
> >
> > 3. And how does it differ from the current mechanism?
> >
> > 4. Why specifically multiple PRs instead of Jira tickets?
> >
> > Have you seen similar practices in other public projects?



-- 
Best wishes,
Amelchev Nikita

Re: Subject: [DISCUSS] Required IEP approval for API, protocol, and storage changes

[Nikolay Izhikov <ni...@apache.org>]

Hello, Kirill.

> Don't you think that by introducing a stricter development process, we might increase development time where it isn't necessary?

The point here - we want to improve decisions quality and long term
API stability.

> 1. You could provide more explanations and examples here.
> Take `SELECT FOR UPDATE`, for instance, which was introduced recently.
> As I understand it, since this was a change to the public API, the procedure should have been to create an IEP, go through its full lifecycle, and only then begin implementation?

Yes.

> What should be done if problems are found in the current IEP, or something was overlooked, and it needs to be improved, does that also require a new IEP?

Yes.

The goal of IEP and voting process is to prevent issues in the API.
So, If we spend more time before pinning API then we will prevent
future broken changes and complete features removal.

> 2. Who will be responsible for verifying that no backward compatibility cases have been overlooked?

IEP author in the first place.
Ignite community as an entity that supports project in a healthy state.

> What do you mean by "support"?
> Who will be responsible for the IEPs and their bug fixes?

Nothing changes here.
Community is responsible for fixing bugs and improving project.

> 3. And how does it differ from the current mechanism?

1. By writing down clear rules what MUST be done with the IEP process:
changes in public API and public behaviour (client, disk formats).
2. By enlarging the number of approvals required to change public things.

> Have you seen similar practices in other public projects?

Yes. Many projects has similar approach:

* Kakfa KIPs - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55155994
* Cassandra CEPs -
https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/95652201/Cassandra+Enhancement+Proposals+CEP
* Spark SPIPs - https://spark.apache.org/improvement-proposals.html
* Pyathon PEPs - https://peps.python.org/

to name a few.
It is much harder to name a project that allows changing public API
with the one approval rather than opposite.

вт, 6 окт. 2026 г. в 09:05, Kirill Tkalenko <tk...@yandex.ru>:
>
> Hi Anton!
>
> I am not in favor of increasing formalism or swinging too far in either direction; doing everything without IEPs, or relying solely on them, both seem concerning at this stage.
>
> I would suggest keeping the current approach where major changes or features require an IEP, while small or minor ones can simply be discussed on the dev list.
>
> Don't you think that by introducing a stricter development process, we might increase development time where it isn't necessary?
>
> Regarding your points:
>
> 1. You could provide more explanations and examples here. Take `SELECT FOR UPDATE`, for instance, which was introduced recently. As I understand it, since this was a change to the public API, the procedure should have been to create an IEP, go through its full lifecycle, and only then begin implementation? What should be done if problems are found in the current IEP, or something was overlooked, and it needs to be improved, does that also require a new IEP?
>
> 2. Who will be responsible for verifying that no backward compatibility cases have been overlooked? What do you mean by "support"? Who will be responsible for the IEPs and their bug fixes?
>
> 3. And how does it differ from the current mechanism?
>
> 4. Why specifically multiple PRs instead of Jira tickets?
>
> Have you seen similar practices in other public projects?

Re:Subject: [DISCUSS] Required IEP approval for API, protocol, and storage changes

[Kirill Tkalenko <tk...@yandex.ru>]

Hi Anton!

I am not in favor of increasing formalism or swinging too far in either direction; doing everything without IEPs, or relying solely on them, both seem concerning at this stage.

I would suggest keeping the current approach where major changes or features require an IEP, while small or minor ones can simply be discussed on the dev list.

Don't you think that by introducing a stricter development process, we might increase development time where it isn't necessary?

Regarding your points:

1. You could provide more explanations and examples here. Take `SELECT FOR UPDATE`, for instance, which was introduced recently. As I understand it, since this was a change to the public API, the procedure should have been to create an IEP, go through its full lifecycle, and only then begin implementation? What should be done if problems are found in the current IEP, or something was overlooked, and it needs to be improved, does that also require a new IEP?

2. Who will be responsible for verifying that no backward compatibility cases have been overlooked? What do you mean by "support"? Who will be responsible for the IEPs and their bug fixes?

3. And how does it differ from the current mechanism?

4. Why specifically multiple PRs instead of Jira tickets?

Have you seen similar practices in other public projects?