Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minor: Refine dev/release/README.md #10129

Merged
merged 1 commit into from
Apr 18, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 11 additions & 6 deletions dev/release/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,19 +25,24 @@ Patch releases are made on an adhoc basis, but we try and avoid them given the f

## Branching Policy

- When we prepare a new release, we create a release branch, such as `branch-18` in the Apache repository (not in a fork)
- When we prepare a new release, we create a release branch, such as `branch-37` in the Apache repository (not in a fork)
- We update the crate version and generate the changelog in this branch and create a PR against the main branch
- Once the PR is approved and merged, we tag the rc in the release branch, and release from the release branch
- Bug fixes can be merged to the release branch and patch releases can be created from the release branch

#### How to add changes to `branch-*` branch?

If you would like to propose your change for inclusion in a release branch
If you would like to propose your change for inclusion in a release branch for a
patch release:

1. follow normal workflow to create PR to `main` branch and wait for its approval and merges.
2. after PR is squash merged to `main`, branch from most recent release branch (e.g. `branch-18`), cherry-pick the commit and create a PR to release branch.
1. Find (or create) the issue for the incremental release ([example release issue]) and discuss the proposed change there with the maintainers.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to add some examples of what a release issue and backport PR looked like so we can follow the same example in the future

1. Follow normal workflow to create PR to `main` branch and wait for its approval and merge.
1. After PR is squash merged to `main`, branch from most recent release branch (e.g. `branch-37`), cherry-pick the commit and create a PR targeting the release branch [example backport PR].

## Prerequisite
[example release issue]: https://github.com/apache/arrow-datafusion/issues/9904
[example backport pr]: https://github.com/apache/arrow-datafusion/pull/10123

## Release Prerequisite

- Have upstream git repo `git@github.com:apache/arrow-datafusion.git` add as git remote `apache`.
- Created a personal access token in GitHub for changelog automation script.
Expand Down Expand Up @@ -121,7 +126,7 @@ This process is not fully automated, so there are some additional manual steps:
Prepare a PR to update `CHANGELOG.md` and versions to reflect the planned
release.

See [#801](https://github.com/apache/arrow-datafusion/pull/801) for an example.
See [#9697](https://github.com/apache/arrow-datafusion/pull/9697) for an example.

Here are the commands that could be used to prepare the `5.1.0` release:

Expand Down