Release Management#

This page describes DataFusion release branches and backports. For the maintainer release guide, including release candidate artifacts, voting, and publication, see the release process README in dev/release.

Overview#

DataFusion typically has a major release about once per month, including breaking API changes. Patch releases are made on an ad hoc basis, but we try to avoid them because major releases are frequent.

New development happens on the main branch. Releases are made from release branches named branch-NN, such as branch-50 for the 50.x.y release series.

In general:

  • New features land on [main]

  • Patch releases are cut from the corresponding branch-NN

  • Only targeted, low-risk fixes should be added to a release branch

Changes reach a release branch in one of two ways:

  • (Most common) Fix the issue on main and then backport the merged change to the release branch

  • Fix the issue on the release branch and then forward-port the change to main

Releases are coordinated in a GitHub issue, such as the release issue for 50.3.0. If you think a fix should be included in a patch release, discuss it on the relevant tracking issue first. You can also open the backport PR first and then link it from the tracking issue.

To prepare for a new release series, maintainers:

  • Create a new branch from main, such as branch-50, in the Apache repository

  • Continue merging new features to main

  • Prepare the release branch for release by updating versions, changelog content, and any additional release-specific fixes via the Backport Workflow

  • Create release candidate artifacts from the release branch

  • After approval, publish to crates.io, ASF distribution servers, and Git tags

Backport Workflow#

The usual workflow is:

  1. Fix on main first, and merge the fix via a normal PR workflow.

  2. Cherry-pick the merged commit onto the release branch.

  3. Open a backport PR targeting the release branch (examples below).

Inputs#

To backport a change, gather the following information:

  • Target branch, such as apache/branch-52

  • The release tracking issue URL, such as https://github.com/apache/datafusion/issues/19692

  • The original PR URL, such as https://github.com/apache/datafusion/pull/20192

  • Optional explicit commit SHA to backport

Apply the Backport#

Start from the target release branch, create a dedicated backport branch, and use git cherry-pick. For example, to backport PR #1234 to branch-52 when the commit SHA is abc123, run:

git checkout apache/branch-52
git checkout -b alamb/backport_1234
git cherry-pick abc123

Test#

Run tests as described in the testing documentation.

Open the PR#

Create a PR against the release branch, not main, and prefix it with [branch-NN] to show which release branch the backport targets. For example:

  • [branch-52] fix: validate inter-file ordering in eq_properties() (#20329)

Use a PR description that links the tracking issue, original PR, and target branch, for example:

- Part of <tracking-issue-url>
- Closes <backport-issue-url> on <branch-name>

This PR:

- Backports <original-pr-url> from @<author> to the <branch-name> line