Originally raised by @mbutrovich
The current release_management.md documents the mechanics of backporting (cherry-pick, PR title, examples) but does not state which kinds of changes are appropriate for a release branch — only the general line "Only targeted, low-risk fixes should be added."
This leaves contributors and release managers re-litigating the same case-by-case questions on every patch release (Is this perf fix in scope? What about a refactor that fixes a latent bug? A new error message?), and the answers are not discoverable to first-time backporters.
This proposal adds a written Backport Criteria section - modeled on Apache Spark's versioning policy that enumerates what is eligible, what is not recommended, how behavior-changing fixes are handled, and who decides. The goal is to set a clear, predictable bar for release branches, reduce churn during stabilization, and make the release manager's gatekeeping role explicit rather than tacit.
The proposal is a easy start doc, ported from Apache Spark, however we need to consider DataFusion family of downstream projects
FYI @milenkovicm @gabotechs @andygrove @timsaucer @adriangb
The context:
Originally posted by @comphead in #21080
Originally raised by @mbutrovich
The current
release_management.mddocuments the mechanics of backporting (cherry-pick, PR title, examples) but does not state which kinds of changes are appropriate for a release branch — only the general line "Only targeted, low-risk fixes should be added."This leaves contributors and release managers re-litigating the same case-by-case questions on every patch release (Is this perf fix in scope? What about a refactor that fixes a latent bug? A new error message?), and the answers are not discoverable to first-time backporters.
This proposal adds a written Backport Criteria section - modeled on Apache Spark's versioning policy that enumerates what is eligible, what is not recommended, how behavior-changing fixes are handled, and who decides. The goal is to set a clear, predictable bar for release branches, reduce churn during stabilization, and make the release manager's gatekeeping role explicit rather than tacit.
The proposal is a easy start doc, ported from Apache Spark, however we need to consider DataFusion family of downstream projects
FYI @milenkovicm @gabotechs @andygrove @timsaucer @adriangb
The context:
Originally posted by @comphead in #21080