> 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 > > > > > >
