chore: Define backport criteria#22766
Conversation
github-actions
Bot
added
the
documentation
| ### Behavior changes | ||
|
|
||
| A "behavior change" is any fix that alters user-visible results: SQL | ||
| semantics (values, ordering, types, null handling), error messages that |
There was a problem hiding this comment.
I think we have made error message changes in minor releases before and it seems like that would be ok to me, to be honest.
The rest of this sounds good
| returning different results. Before opening the backport PR: | ||
|
|
||
| 1. State on the release tracking issue _why_ the change must ship in this | ||
| patch release rather than the next major. | ||
| 2. Describe the previous and new behavior with example queries and results. | ||
| 3. Wait for explicit acknowledgment from the release manager or another | ||
| committer on the tracking issue. |
There was a problem hiding this comment.
I am not sure we need to gate the creation of a backport PR on acknowledgement from the release manager -- making the backport PR is pretty simple, and I would expect that 2. (describing previous behavior, etc) would have already been done on the main issue
Explaining why you want the change in the patch release is a good idea though.
|
|
||
| ### Who decides | ||
|
|
||
| The release manager for the active release line is the final reviewer of |
There was a problem hiding this comment.
I think practically any committer can commit to a release branch too -- so maybe we can make ti clear that others can merge PRs to the release branch, though the release manager will review them
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
…22822) ## Which issue does this PR close? - Part of apache#22765 - Related to apache#19783. ## Rationale for this change While reviewing apache#22766 from @comphead I noticed that the release management guide did not point contributors to the ongoing release tracking issue, where planned releases are listed. ## What changes are included in this PR? This PR adds a link to the DataFusion Releases tracking issue from the release management guide and clarifies that each release is coordinated in a dedicated GitHub issue. ## Are these changes tested? Not run. This is a documentation-only change. ## Are there any user-facing changes? No API or behavior changes. This updates contributor documentation only.
|
Concern we running code CI for documentation PRs, which doesn't make a lot of sense. |
|
Thanks @alamb for the review |
2 participants
Which issue does this PR close?
Rationale for this change
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?