wjones127 commented on code in PR #33660: URL: https://github.com/apache/arrow/pull/33660#discussion_r1070134895
########## .github/pull_request_template.md: ########## @@ -57,5 +57,11 @@ If there are user-facing changes then we may require documentation to be updated --> <!-- -If there are any breaking changes to public APIs, please add the `breaking-change` label. ---> \ No newline at end of file +If there are any breaking changes to public APIs, please uncomment the following line: +--> +<!-- **This PR includes breaking changes to public APIs.** --> + +<!-- +If the changes fix either a security vulnerability or a bug that caused incorrect or invalid data to be produced. This is intended to mark changes that may affect users without their knowledge. For this reason, fixing bugs that cause errors or crashes don't count, since those are usually obvious. +--> Review Comment: Hmm I guess I should clarify since Rok had the same question. The difference is "Breaking Change" is when we change our promise about how an API behaves, while "Critical Fix" changes the implementation to align with the existing promise. For example, if we have a function `add(x, y)` that promised to add two numbers, but we found that `add(2, 2)` returned `5`, fixing that to return `4` is a Critical Fix, not a breaking change. In the Arrow project, this typically shows up in file readers and writers, where we sometimes parse or serialize data incorrectly. Fixing those bugs don't really constitute breaking changes IMO. Another way to put it is "Breaking Changes" are the reasons you might not want to upgrade until you have time to adapt your code, while "Critical Changes" highlight the risk of *not* upgrading. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
