+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 <[email protected]> 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 <[email protected]>: > > > > 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
