Hello Arrow devs, For the monorepo, I would like to propose adding two new labels to issues:
1. breaking-change: for changes that break API compatibility. 2. critical-fix: for bug fixes that address bugs that are important for users will want to know about, but may not realize affect them. The primary type I have observed in the Arrow repo are bugs that produce incorrect or invalid data. Security vulnerabilities are another type. Bugs that caused errors or crashes generally wouldn't count, since users are aware of the errors they get. (Though I am definitely open to arguments for a different definition or name.) I would additionally propose that these labels are validated during the release process and included in the change notes. By validated, I mean someone should review all the changes in a particular release to make sure all relevant issues are tagged with these labels. These are the two kinds of issues I think users will most want to know about when considering upgrading an Arrow library: what APIs changed? And what's the risk of not upgrading? I am willing to be responsible for maintaining these labels for the next few releases for Python, R, and C++. I have been compiling the list of these issues for past versions, as part of my work for my employer, so I'm on the hook for this regardless. Having these labels available and used by developers and reviewers would make that work much easier. And, of course, our users would benefit by having this information easily available in our release notes. It's also worth mentioning these two labels are useful if we decide to change how we do releases. The breaking-change label can help decide whether we actually need to increment the major version. And the critical-fix label can help guide which bug fixes are worth applying to older supported releases. I don't think we are ready for either of those yet, but I thought it's worth connecting those dots. Best, Will Jones
