I'd like to propose one more rule: 3. The PR should update `upgrade.html` ( https://github.com/apache/kafka/blob/trunk/docs/upgrade.html#L25) if it brings a breaking change.
Best, Chia-Ping Divij Vaidya <divijvaidy...@gmail.com> 於 2024年11月6日 週三 上午12:04寫道： > Hi folks > > We would be making many breaking changes in 4.0 such as removal of > deprecated metrics, removal of configs etc. > > It would be nice if we can document all such backward incompatible > behaviour in our documentation. The alternative is to leave the user with > trying to figure out which changes are breaking from the release notes, > which is quite challenging since not all users may be familiar with > details. > > Hence, I propose the following: > 1. Add a label "breaking" to the JIRAs scheduled for release in 4.0 which > contain backward incompatible changes to public interfaces. > 2. During the release process, we will document a "guidance for upgrade" > which will call out breaking changes per component. > > For this proposal to be successful, all committers should be mindful of > adding the "breaking" label when closing a JIRA as resolved. > > Thoughts? > > -- > Divij Vaidya >
