You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "A. Sophie Blee-Goldman (Jira)" <ji...@apache.org> on 2023/11/03 04:49:00 UTC

[jira] [Created] (KAFKA-15782) Establish concrete project conventions to define public APIs that require a KIP

A. Sophie Blee-Goldman created KAFKA-15782:
----------------------------------------------

             Summary: Establish concrete project conventions to define public APIs that require a KIP
                 Key: KAFKA-15782
                 URL: https://issues.apache.org/jira/browse/KAFKA-15782
             Project: Kafka
          Issue Type: Improvement
            Reporter: A. Sophie Blee-Goldman


There seems to be no concrete definition that establishes project-specific conventions for what is and is not considered a public API change that requires a KIP. This results in frequent drawn-out debates that revisit the same topic and slow things down, and often ends up forcing trivial changes through the KIP process. For a recent example, KIP-998 was required for a one-line change just to add the "protected" access modifier to an otherwise package-private class. See [this comment thread|https://github.com/apache/kafka/pull/14681#discussion_r1378591228] for the full debate on this subject.

It would be beneficial and in the long run save us all time to just sit down and hash out the project conventions, such as whether a package-private/protected method on a non-final java class is to be considered a public API, even if the method itself is/was never a public method. This will of course require a KIP, but should help to establish some ground rules to avoid any more superfluous KIPs in the future



--
This message was sent by Atlassian Jira
(v8.20.10#820010)