Antoine, I think the challenge is to maintain a shared understanding and definition > of what these terms cover and don't cover.
I agree with this. I'd propose that we have a page in our Contributing docs (perhaps the reviewers page?) that defines the criteria for these labels. I can make a PR with this next week. Rok, 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]. I replied in the GitHub thread [1], but will say that I am +1 on Priority: Blocker and Priority: Critical. Though I wonder if we could use "Critical Fix" in place of "Priority: Critical"? Unless we have two different definitions. As is, the names are similar enough that it could be confusing. Perhaps I can draft a full definition of "Critical Fix", and then we can discuss based on that? (I assume at the very least that Priority Critical never refers to features, right?) [1] https://github.com/apache/arrow/issues/14593 On Fri, Jan 6, 2023 at 12:50 PM Matthew Topol <m...@voltrondata.com.invalid> wrote: > > To answer Matt's comment, though: those are not necessarily the criteria > for minor releases, if we think of the latter as bugfix releases. > > When we do bugfixes, we release them as Patch releases (which I'd argue is > correct). In an ideal world, we'd only do a *major* version release when > there are breaking changes and otherwise features would go out with minor > releases. Bugfixes staying with patch releases. > > That's just how I think of them though, obviously there's difficulty with a > monorepo in being sure we know what is or isn't a breaking change (which > the proposed labels will absolutely help with). While the label doesn't > solve the complexities, it definitely moves us forward I think. > > --Matt > > On Fri, Jan 6, 2023 at 3:44 PM Rok Mihevc <rok.mih...@gmail.com> wrote: > > > 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 > > > > > > > > > >
