I'm extremely in favor of both of these labels for the reasons you state Will. It would be great to see us shift towards being able to do minor releases and not *always* having to do a major version release.
--Matt On Fri, Jan 6, 2023 at 12:14 PM Micah Kornfield <emkornfi...@gmail.com> wrote: > These sounds good to me, we should be careful around crashes/security > issues to not tag them until they are triaged and we decide if a new > one-off release is necessary. > > On Fri, Jan 6, 2023 at 8:57 AM Will Jones <will.jones...@gmail.com> wrote: > > > 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 > > >
