"backport candidate" sounds like an interesting idea! If someone wants to propose and help implement that, I would be supportive.
For now, I've merged the definitions of "Breaking Change" and "Critical Fix". I've also labelled the relevant issues I've found for 11.0.0 and 10.0.0: Breaking changes in 11.0.0: https://github.com/apache/arrow/issues?q=milestone%3A%2211.0.0%22+label%3A%22Breaking+Change%22 Critical fixes in 11.0.0: https://github.com/apache/arrow/issues?q=milestone%3A%2211.0.0%22+label%3A%22Critical+Fix%22+ Breaking changes in 10.0.0: https://github.com/apache/arrow/issues?q=milestone%3A%2210.0.0%22+label%3A%22Breaking+Change%22+ Critical fixes in 10.0.0: https://github.com/apache/arrow/issues?q=milestone%3A%2210.0.0%22+label%3A%22Critical+Fix%22+ On Tue, Jan 17, 2023 at 8:17 AM Antoine Pitrou <anto...@python.org> wrote: > > Hi, > > I would also suggest a "bugfix" or "backport candidate" label if we want > to make it easier to cherrypick changes for bugfix releases. > > Regards > > Antoine. > > > Le 06/01/2023 à 17:57, Will Jones a écrit : > > 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 > > >
