Thanks everyone involved! Nikolay, thanks for your support!
Kirill, the goal is to create a useful and powerful process instead of formalism. Nikita, > Could you clarify how API deprecation and removal would be handled? TBD, let's think about it. Any proposals? Aleksandr, > do we have a clear definition of "Public APIs or their supported behavior"? TBD again. My goal is to start this change and (maybe) lead it. I don't know all the answers, let's start with some proposals. Dmitry, > I believe we need to more precisely specify which public API changes require an IEP Any. Not a joke. Any public, but the question of what is public is still a question. Start case is the disk and communications formats, public Ignite Java API (not internal classes). Feel free to add something. Vladislav, > Could we allow revisions to the existing IEP Sure, common sense is our power. > What makes an IEP ready for approval, and how do we determine that its implementation is complete? Same answer; let's start with common sense and see how it's going. > Can we automatically flag or block PRs that change public APIs or behavior requiring an IEP but have no linked IEP? Hope to know how :) Let's start with a simple statement and a simple document via the Developer's Guide page, and take a look. On Tue, Oct 6, 2026 at 2:53 PM Vladislav Pyatkov <[email protected]> wrote: > Hi all, > > 1. Tying a vote to a specific version of an IEP makes sense. However, > requiring a new IEP for every correction or refinement seems excessive. > Could we allow revisions to the existing IEP, preserving the approved > version and putting substantial changes through another review and vote? > 2. What makes an IEP ready for approval, and how do we determine that > its implementation is complete? Is a description of the functionality > with > explicit completion criteria enough, or is an exhaustive list of linked > implementation tickets required? > 3. How would we enforce this rule during code review? Can we > automatically flag or block PRs that change public APIs or behavior > requiring an IEP but have no linked IEP? Or would identifying such > changes > remain entirely the reviewers’ responsibility? > > > On Tue, Oct 6, 2026 at 2:17 PM Dmitry Werner <[email protected]> wrote: > > > Hi all, > > > > +1 overall. > > > > I believe we need to more precisely specify which public API changes > > require an IEP (for example, adding metrics, modifying log messages, > etc.) > > so that the rules are unambiguous for everyone. > > > > Aleksandr's questions about log messages and internode messages are a > good > > illustration of why this clarification matters. > > > > On Tue, Oct 6, 2026 at 3:37 PM Aleksandr Chesnokov < > > [email protected]> > > wrote: > > > > > Hi all, > > > > > > > > > Adding to Kirill's questions: do we have a clear definition of "Public > > > APIs or their supported behavior"? To be more specific: > > > > > > 1. Are log messages part of the public API? As far as I know, some > users > > > build grep scripts on top of Ignite logs. > > > > > > 2. Are internode messages part of the public API? Should we create an > IEP > > > for a change of the wire protocol (the order of fields in a message, > for > > > example)? > > > > > > As an example, Hadoop has an explicit compatibility guide [1] which > > > declares audience (who may rely on it) and stability (how freely it may > > > change) for each kind of interface. The two are separate: log output is > > > "Public and Unstable" [2], server-server wire protocols are "Private > and > > > Stable" by default [3]. Maybe we can add a similar list to the > proposal? > > > > > > > > > [1] > > > > > > https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Compatibility.html > > > [2] > > > > > > https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Compatibility.html#Log_Output > > > [3] > > > > > > https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Compatibility.html#Wire_Protocols > > > > > -- > Vladislav Pyatkov >
