Hey, +1 for the proposal. Perhaps we can loop back and evaluate come 12.0.0 to see if these were useful / used?
I'd like to pile on another new label proposal. For purpose of Jira -> GitHub Migration I'd like to propose the following labels be added, that are common on Jira but missing on GitHub: "Priority: Blocker", "Priority: Critical", "Priority: Major", "Priority: Minor", "Priority: Trivial", "good-second-issue". This would give us a better mapping to Jira. See discussion here [1]. [1] https://github.com/apache/arrow/issues/14593 Rok On Fri, Jan 6, 2023 at 6:49 PM Antoine Pitrou <anto...@python.org> wrote: > > Hello Will, > > This sounds like a good idea. I think the challenge is to maintain a > shared understanding and definition of what these terms cover and don't > cover. > > To answer Matt's comment, though: those are not necessarily the criteria > for minor releases, if we think of the latter as 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 > > >
