docs/source/contributor-guide/release_management.md - datafusion - Git at Google


            
            <!---

            
              Licensed to the Apache Software Foundation (ASF) under one

            
              or more contributor license agreements.  See the NOTICE file

            
              distributed with this work for additional information

            
              regarding copyright ownership.  The ASF licenses this file

            
              to you under the Apache License, Version 2.0 (the

            
              "License"); you may not use this file except in compliance

            
              with the License.  You may obtain a copy of the License at


                http://www.apache.org/licenses/LICENSE-2.0


              Unless required by applicable law or agreed to in writing,

            
              software distributed under the License is distributed on an

            
              "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY

            
              KIND, either express or implied.  See the License for the

            
              specific language governing permissions and limitations

            
              under the License.

            
            -->


            # 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 using GitHub issues. Each planned release is listed in

            
            the [DataFusion Releases tracking issue], and each release is coordinated in a

            
            dedicated 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

            
            or open a backport PR and link it there.


            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](#backport-workflow)

            
            - Create release candidate artifacts from the release branch

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


            ## Backport Criteria


            A release branch is a stabilization branch for an imminent or recent patch

            
            release. The bar for landing a change on a release branch is therefore

            
            _higher_ than the bar for landing on `main`, not lower. These criteria define

            
            what is eligible for backport; the [Backport Workflow](#backport-workflow)

            
            below describes the mechanics.


            DataFusion follows Cargo SemVer, with breaking changes allowed at major

            
            version boundaries — see the [API health policy] for the full framing of

            
            public Rust and SQL API stability. Patch releases (`x.y.z`, `z ≥ 1`) carry

            
            fixes only and never introduce new features or breaking changes.


            ### Eligible for backport


            - **Security fixes.** Fixes for known or reported security issues should be

            
              backported to every actively maintained release branch.

            
            - **Correctness fixes.** Fixes for queries that produce incorrect results,

            
              panics, data loss, or crashes. If the fix itself changes user-visible SQL

            
              semantics to make a wrong result right, follow [Behavior changes] below.

            
            - **Stability and regression fixes.** Fixes for regressions introduced in the

            
              current release line, hangs, deadlocks, memory leaks, or other availability

            
              issues.

            
            - **Build, CI, and test fixes** required to keep the branch buildable and

            
              releasable.

            
            - **Documentation fixes** for behavior already in the release. Documentation

            
              for behavior that exists only on `main` does not belong on a release branch.


            ### Not recommended for backport


            - **New features**, including new SQL functions, new optimizer rules, new

            
              configuration options, new public APIs, and new file-format support. Land

            
              on `main` and ship in the next major release.

            
            - **Breaking API changes** of any kind, Rust or SQL. DataFusion makes

            
              breaking changes only at major version boundaries — see [API health policy].

            
            - **Refactors and cleanup** that do not fix a bug, even if they are correct.

            
            - **Performance improvements** that are not also correctness or stability

            
              fixes. Land on `main`.

            
            - **Dependency upgrades**, except when the upgrade itself is the security or

            
              correctness fix and there is no narrower alternative.


            ### Behavior changes


            A "behavior change" is any fix that alters user-visible results: SQL

            
            semantics (values, ordering, types, null handling), error messages that

            
            downstream users may rely on, plan output, or default configuration values.


            Behavior-changing fixes need extra scrutiny on a release branch because

            
            users upgrading between patch versions do not expect their queries to start

            
            returning different results. When proposing one for backport, state on the

            
            release tracking issue _why_ the change should ship in this patch release

            
            rather than wait for the next major. The previous and new behavior should

            
            already be documented on the original issue or PR — link to that rather

            
            than restating it.


            If in doubt, default to "land on `main`, ship in the next major."


            ### Who decides


            The release manager for the active release line is the final reviewer of

            
            what goes into the patch release. They coordinate via the release tracking

            
            issue (for example, the [release issue for 50.3.0]). Anyone may propose a

            
            backport by opening a backport PR and linking it from the tracking issue;

            
            inclusion is the release manager's call.


            ### Active release branches


            DataFusion does not maintain Long-Term Support branches. In general only the

            
            most recent `branch-NN` is actively maintained for backports, but if you need

            
            fixes in older releases, we are open to discussion.


            Security fixes are an exception: a maintainer may choose to backport a

            
            critical security fix to an older branch even after it would otherwise be

            
            closed. Discuss on the dev list or in a tracking issue before doing so.


            ## 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).


            - [Example backport PR]

            
            - [Additional backport PR example]


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


            ```bash

            
            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:


            ```markdown

            
            - 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

            
            ```


            [`main` branch]: https://github.com/apache/datafusion/tree/main

            
            [`branch-50`]: https://github.com/apache/datafusion/tree/branch-50

            
            [the release process readme in `dev/release`]: https://github.com/apache/datafusion/blob/main/dev/release/README.md

            
            [datafusion releases tracking issue]: https://github.com/apache/datafusion/issues/19783

            
            [release issue for 50.3.0]: https://github.com/apache/datafusion/issues/18072

            
            [example backport pr]: https://github.com/apache/datafusion/pull/18131

            
            [additional backport pr example]: https://github.com/apache/datafusion/pull/20792

            
            [testing documentation]: testing.md

            
            [api health policy]: api-health.md

            
            [behavior changes]: #behavior-changes
	<!---
	Licensed to the Apache Software Foundation (ASF) under one
	or more contributor license agreements. See the NOTICE file
	distributed with this work for additional information
	regarding copyright ownership. The ASF licenses this file
	to you under the Apache License, Version 2.0 (the
	"License"); you may not use this file except in compliance
	with the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing,
	software distributed under the License is distributed on an
	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	KIND, either express or implied. See the License for the
	specific language governing permissions and limitations
	under the License.
	-->

	# 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 using GitHub issues. Each planned release is listed in
	the [DataFusion Releases tracking issue], and each release is coordinated in a
	dedicated 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
	or open a backport PR and link it there.

	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](#backport-workflow)
	- Create release candidate artifacts from the release branch
	- After approval, publish to crates.io, ASF distribution servers, and Git tags

	## Backport Criteria

	A release branch is a stabilization branch for an imminent or recent patch
	release. The bar for landing a change on a release branch is therefore
	_higher_ than the bar for landing on `main`, not lower. These criteria define
	what is eligible for backport; the [Backport Workflow](#backport-workflow)
	below describes the mechanics.

	DataFusion follows Cargo SemVer, with breaking changes allowed at major
	version boundaries — see the [API health policy] for the full framing of
	public Rust and SQL API stability. Patch releases (`x.y.z`, `z ≥ 1`) carry
	fixes only and never introduce new features or breaking changes.

	### Eligible for backport

	- Security fixes. Fixes for known or reported security issues should be
	backported to every actively maintained release branch.
	- Correctness fixes. Fixes for queries that produce incorrect results,
	panics, data loss, or crashes. If the fix itself changes user-visible SQL
	semantics to make a wrong result right, follow [Behavior changes] below.
	- Stability and regression fixes. Fixes for regressions introduced in the
	current release line, hangs, deadlocks, memory leaks, or other availability
	issues.
	- Build, CI, and test fixes required to keep the branch buildable and
	releasable.
	- Documentation fixes for behavior already in the release. Documentation
	for behavior that exists only on `main` does not belong on a release branch.

	### Not recommended for backport

	- New features, including new SQL functions, new optimizer rules, new
	configuration options, new public APIs, and new file-format support. Land
	on `main` and ship in the next major release.
	- Breaking API changes of any kind, Rust or SQL. DataFusion makes
	breaking changes only at major version boundaries — see [API health policy].
	- Refactors and cleanup that do not fix a bug, even if they are correct.
	- Performance improvements that are not also correctness or stability
	fixes. Land on `main`.
	- Dependency upgrades, except when the upgrade itself is the security or
	correctness fix and there is no narrower alternative.

	### Behavior changes

	A "behavior change" is any fix that alters user-visible results: SQL
	semantics (values, ordering, types, null handling), error messages that
	downstream users may rely on, plan output, or default configuration values.

	Behavior-changing fixes need extra scrutiny on a release branch because
	users upgrading between patch versions do not expect their queries to start
	returning different results. When proposing one for backport, state on the
	release tracking issue _why_ the change should ship in this patch release
	rather than wait for the next major. The previous and new behavior should
	already be documented on the original issue or PR — link to that rather
	than restating it.

	If in doubt, default to "land on `main`, ship in the next major."

	### Who decides

	The release manager for the active release line is the final reviewer of
	what goes into the patch release. They coordinate via the release tracking
	issue (for example, the [release issue for 50.3.0]). Anyone may propose a
	backport by opening a backport PR and linking it from the tracking issue;
	inclusion is the release manager's call.

	### Active release branches

	DataFusion does not maintain Long-Term Support branches. In general only the
	most recent `branch-NN` is actively maintained for backports, but if you need
	fixes in older releases, we are open to discussion.

	Security fixes are an exception: a maintainer may choose to backport a
	critical security fix to an older branch even after it would otherwise be
	closed. Discuss on the dev list or in a tracking issue before doing so.

	## 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).

	- [Example backport PR]
	- [Additional backport PR example]

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

	```bash
	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:

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

	[`main` branch]: https://github.com/apache/datafusion/tree/main
	[`branch-50`]: https://github.com/apache/datafusion/tree/branch-50
	[the release process readme in `dev/release`]: https://github.com/apache/datafusion/blob/main/dev/release/README.md
	[datafusion releases tracking issue]: https://github.com/apache/datafusion/issues/19783
	[release issue for 50.3.0]: https://github.com/apache/datafusion/issues/18072
	[example backport pr]: https://github.com/apache/datafusion/pull/18131
	[additional backport pr example]: https://github.com/apache/datafusion/pull/20792
	[testing documentation]: testing.md
	[api health policy]: api-health.md
	[behavior changes]: #behavior-changes