mbutrovich commented on code in PR #18549: URL: https://github.com/apache/datafusion/pull/18549#discussion_r2506876601
########## dev/release/README.md: ########## @@ -23,55 +23,85 @@ DataFusion typically has major releases around once per month, including breakin Patch releases are made on an adhoc basis, but we try and avoid them given the frequent major releases. -## Branching Policy +## Release Process Overview -- 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 +New development happens on the `main` branch. +Releases are made from branches, e.g. `branch-37` for the `37.x.y` release series. -#### How to backport (add changes) to `branch-*` branch +To prepare for a new release series, we: -If you would like to propose your change for inclusion in a release branch for a -patch release: +- Create a new release branch from `main`, such as `branch-37` in the Apache repository (not in a fork) +- Continue merging new features changes to `main` branch +- Prepare the release branch for release: + - Update version numbers in `Cargo.toml` files and create `CHANGELOG.md` + - Backport any needed changes from `main` to the release branch +- When the code is ready, we create github tags and create release candidate (rc) artifacts from the release branch. Review Comment: ```suggestion - When the code is ready, we create GitHub tags and create release candidate (rc) artifacts from the release branch. ``` ########## dev/release/README.md: ########## @@ -23,55 +23,85 @@ DataFusion typically has major releases around once per month, including breakin Patch releases are made on an adhoc basis, but we try and avoid them given the frequent major releases. -## Branching Policy +## Release Process Overview -- 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 +New development happens on the `main` branch. +Releases are made from branches, e.g. `branch-37` for the `37.x.y` release series. -#### How to backport (add changes) to `branch-*` branch +To prepare for a new release series, we: -If you would like to propose your change for inclusion in a release branch for a -patch release: +- Create a new release branch from `main`, such as `branch-37` in the Apache repository (not in a fork) +- Continue merging new features changes to `main` branch +- Prepare the release branch for release: + - Update version numbers in `Cargo.toml` files and create `CHANGELOG.md` + - Backport any needed changes from `main` to the release branch +- When the code is ready, we create github tags and create release candidate (rc) artifacts from the release branch. +- After the release is approved, we publish to crates.io, the ASF distribution servers, and github tags. + +For patch releases, we backport changes from `main` to the release branch as +needed and repeat the release process as needed Review Comment: ```suggestion needed and repeat the release process as needed. ``` ########## dev/release/README.md: ########## @@ -23,55 +23,85 @@ DataFusion typically has major releases around once per month, including breakin Patch releases are made on an adhoc basis, but we try and avoid them given the frequent major releases. -## Branching Policy +## Release Process Overview -- 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 +New development happens on the `main` branch. +Releases are made from branches, e.g. `branch-37` for the `37.x.y` release series. -#### How to backport (add changes) to `branch-*` branch +To prepare for a new release series, we: -If you would like to propose your change for inclusion in a release branch for a -patch release: +- Create a new release branch from `main`, such as `branch-37` in the Apache repository (not in a fork) +- Continue merging new features changes to `main` branch +- Prepare the release branch for release: + - Update version numbers in `Cargo.toml` files and create `CHANGELOG.md` + - Backport any needed changes from `main` to the release branch +- When the code is ready, we create github tags and create release candidate (rc) artifacts from the release branch. +- After the release is approved, we publish to crates.io, the ASF distribution servers, and github tags. Review Comment: ```suggestion - After the release is approved, we publish to crates.io, the ASF distribution servers, and GitHub tags. ``` ########## dev/release/README.md: ########## @@ -23,55 +23,85 @@ DataFusion typically has major releases around once per month, including breakin Patch releases are made on an adhoc basis, but we try and avoid them given the frequent major releases. -## Branching Policy +## Release Process Overview -- 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 +New development happens on the `main` branch. +Releases are made from branches, e.g. `branch-37` for the `37.x.y` release series. -#### How to backport (add changes) to `branch-*` branch +To prepare for a new release series, we: -If you would like to propose your change for inclusion in a release branch for a -patch release: +- Create a new release branch from `main`, such as `branch-37` in the Apache repository (not in a fork) +- Continue merging new features changes to `main` branch +- Prepare the release branch for release: + - Update version numbers in `Cargo.toml` files and create `CHANGELOG.md` + - Backport any needed changes from `main` to the release branch +- When the code is ready, we create github tags and create release candidate (rc) artifacts from the release branch. +- After the release is approved, we publish to crates.io, the ASF distribution servers, and github tags. + +For patch releases, we backport changes from `main` to the release branch as +needed and repeat the release process as needed + +## Backporting (add changes) to `branch-*` branch + +If you would like to propose your change for inclusion in patch release, the +change must be applied to the relevant release branch. To do so please follow +these steps: 1. Find (or create) the issue for the incremental release ([example release issue]) and discuss the proposed change there with the maintainers. 2. Follow normal workflow to create PR to `main` branch and wait for its approval and merge. 3. 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]. -For example, to backport commit `12345` from `main` to `branch-43`: +For example, to backport commit `12345` from `main` to `branch-50`: ```shell -git checkout branch-43 -git checkout -b backport_to_43 -git cherry-pick 12345 +git checkout branch-50 +git checkout -b backport_to_50 +git cherry-pick 12345 # your git commit hash git push -u <your fork> -# make a PR as normal +# make a PR as normal targeting branch-50, prefixed with [branch-50] +``` + +It is also acceptable to fix the issue directly on the release branch first +and then cherry-pick the change back to `main` branch in a new PR. + +[example release issue]: https://github.com/apache/datafusion/issues/18072 +[example backport pr]: https://github.com/apache/datafusion/pull/18131 + +## Release Prerequisites + +### Add git remote for `apache` repo + +The instructions below assume the upstream git repo `[email protected]:apache/datafusion.git` in remote `apache`. + +```shell +git remote add apache [email protected]:apache/datafusion.git ``` -[example release issue]: https://github.com/apache/datafusion/issues/9904 -[example backport pr]: https://github.com/apache/datafusion/pull/10123 +### Create GitHub Personal Access Token (PAT) + +A personal access token (PAT) is needed for changelog automation script. If you +do not already have one, create a token with the `repo` access by navigating to +[GitHub Developer Settings] page, and [follow these steps]. -## Release Prerequisite +[github developer settings]: https://github.com/settings/developers +[follow these steps]: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token -- Have upstream git repo `[email protected]:apache/datafusion.git` add as git remote `apache`. -- Created a personal access token in GitHub for changelog automation script. - - Github PAT should be created with `repo` access -- Make sure your signing key is added to the following files in SVN: - - https://dist.apache.org/repos/dist/dev/datafusion/KEYS - - https://dist.apache.org/repos/dist/release/datafusion/KEYS +### Add GPG Public Key to SVN `KEYS` file -### How to add signing key +If you will be releasing the final tarball, your GPG public key must be present in the following SVN files: + +- https://dist.apache.org/repos/dist/dev/datafusion/KEYS +- https://dist.apache.org/repos/dist/release/datafusion/KEYS See instructions at https://infra.apache.org/release-signing.html#generate for generating keys. -Committers can add signing keys in Subversion client with their ASF account. e.g.: +Committers can add signing keys using the Subversion client and their ASF account. e.g.: Review Comment: ```suggestion Committers can add signing keys using the Subversion client and their ASF account: ``` ########## dev/release/README.md: ########## @@ -23,55 +23,85 @@ DataFusion typically has major releases around once per month, including breakin Patch releases are made on an adhoc basis, but we try and avoid them given the frequent major releases. -## Branching Policy +## Release Process Overview -- 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 +New development happens on the `main` branch. +Releases are made from branches, e.g. `branch-37` for the `37.x.y` release series. -#### How to backport (add changes) to `branch-*` branch +To prepare for a new release series, we: -If you would like to propose your change for inclusion in a release branch for a -patch release: +- Create a new release branch from `main`, such as `branch-37` in the Apache repository (not in a fork) +- Continue merging new features changes to `main` branch +- Prepare the release branch for release: + - Update version numbers in `Cargo.toml` files and create `CHANGELOG.md` + - Backport any needed changes from `main` to the release branch +- When the code is ready, we create github tags and create release candidate (rc) artifacts from the release branch. +- After the release is approved, we publish to crates.io, the ASF distribution servers, and github tags. + +For patch releases, we backport changes from `main` to the release branch as +needed and repeat the release process as needed + +## Backporting (add changes) to `branch-*` branch + +If you would like to propose your change for inclusion in patch release, the Review Comment: ```suggestion If you would like to propose your change for inclusion in a patch release, the ``` ########## dev/release/README.md: ########## @@ -81,35 +111,61 @@ Follow the instructions in the header of the KEYS file to append your key. Here svn commit KEYS -m "Add key for John Doe" ``` -## Process Overview +## Release Process: Step by Step As part of the Apache governance model, official releases consist of signed source tarballs approved by the PMC. +We then use the code in the approved artifacts to release to crates.io. Review Comment: ```suggestion We then publish the code in the approved artifacts to crates.io. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
