Hi Divij, Thanks for raising this! I agree we should have some ways to identify the breaking changes in v4.0.0. As I proposed in another thread, in v4.0.0, instead of tracking with time as before, we should also consider the status of some features because there are some changes only allowed in the major release. So not just for documentation, it is also good for release managers to identify the breaking changes tasks.
Thank you. Luke On Wed, Nov 6, 2024 at 12:37 AM Chia-Ping Tsai <chia7...@gmail.com> wrote: > 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 > > >
