Copilot commented on code in PR #18549:
URL: https://github.com/apache/datafusion/pull/18549#discussion_r2506861484
##########
dev/release/README.md:
##########
@@ -137,119 +198,124 @@ branch-50:
required_approving_review_count: 1
```
-Here are the commands that could be used to prepare the `38.0.0` release:
-
-### Update Version
-
-Checkout the main commit to be released
-
-```shell
-git fetch apache
-git checkout apache/main
-```
-
-Manually update the datafusion version in the root `Cargo.toml` to `38.0.0`.
-
-Run `cargo test` to re-generate some example files:
-
-```shell
-cargo test
-```
-
-Lastly commit the version change:
-
-```shell
-git commit -a -m 'Update version'
-```
-
-## Prepare release candidate artifacts
+### 4. Prepare Release Candidate Artifacts
After the PR gets merged, you are ready to create release artifacts based off
the
merged commit.
(Note you need to be a committer to run these scripts as they upload to the
apache svn distribution servers)
-### Pick a Release Candidate (RC) number
+#### Pick a Release Candidate (RC) number
-Pick numbers in sequential order, with `0` for `rc0`, `1` for `rc1`, etc.
+Pick numbers in sequential order, with `1` for `rc1`, `2` for `rc2`, etc.
-### Create git tag for the release:
+#### Create git Tag for the Release:
While the official release artifacts are signed tarballs and zip files, we also
-tag the commit it was created for convenience and code archaeology.
+tag the commit it was created for convenience and code archaeology. Release
tags
+have the format `<version>` (e.g. `38.0.0`), and release candidates have the
+the format `<version>-rc<rc>` (e.g. `38.0.0-rc0`). See [the list of existing
Review Comment:
Documentation inconsistency: The line states "the the format" which contains
a duplicate word "the". This should be "the format".
```suggestion
format `<version>-rc<rc>` (e.g. `38.0.0-rc0`). See [the list of existing
```
##########
dev/release/README.md:
##########
@@ -312,30 +378,21 @@ Verify that the Cargo.toml in the tarball contains the
correct version
### Publish datafusion-cli on Homebrew
-[`datafusion` formula](https://formulae.brew.sh/formula/datafusion) is
[updated
automatically](https://github.com/Homebrew/homebrew-core/pulls?q=is%3Apr+datafusion+is%3Aclosed),
+Note: [`datafusion` formula](https://formulae.brew.sh/formula/datafusion) is
[updated
automatically](https://github.com/Homebrew/homebrew-core/pulls?q=is%3Apr+datafusion+is%3Aclosed),
so no action is needed.
-### Call the vote
-
-Call the vote on the Arrow dev list by replying to the RC voting thread. The
-reply should have a new subject constructed by adding `[RESULT]` prefix to the
-old subject line.
-
-Sample announcement template:
-
-```
-The vote has passed with <NUMBER> +1 votes. Thank you to all who helped
-with the release verification.
-```
-
-### Add the release to Apache Reporter
+### 10: Add the release to Apache Reporter
Review Comment:
Missing section number: The heading shows "### 10:" but there is no "###
9:". The section numbering skips from step 8 to step 10, which should be
corrected to "### 9:" for consistency.
```suggestion
### 9: Add the release to Apache Reporter
```
##########
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)
+
+Apersonal 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
Review Comment:
Inconsistent capitalization: "[github developer settings]" should be
"[GitHub Developer Settings]" to match the proper noun and the actual page
title.
```suggestion
[GitHub Developer Settings]: https://github.com/settings/developers
```
##########
dev/release/README.md:
##########
@@ -312,30 +378,21 @@ Verify that the Cargo.toml in the tarball contains the
correct version
### Publish datafusion-cli on Homebrew
-[`datafusion` formula](https://formulae.brew.sh/formula/datafusion) is
[updated
automatically](https://github.com/Homebrew/homebrew-core/pulls?q=is%3Apr+datafusion+is%3Aclosed),
+Note: [`datafusion` formula](https://formulae.brew.sh/formula/datafusion) is
[updated
automatically](https://github.com/Homebrew/homebrew-core/pulls?q=is%3Apr+datafusion+is%3Aclosed),
so no action is needed.
-### Call the vote
-
-Call the vote on the Arrow dev list by replying to the RC voting thread. The
-reply should have a new subject constructed by adding `[RESULT]` prefix to the
-old subject line.
-
-Sample announcement template:
-
-```
-The vote has passed with <NUMBER> +1 votes. Thank you to all who helped
-with the release verification.
-```
-
-### Add the release to Apache Reporter
+### 10: Add the release to Apache Reporter
-Add the release to https://reporter.apache.org/addrelease.html?datafusion
using the version number e.g. 38.0.0.
+When you have published the release, please help the project by adding the
release to
+[Apache Reporter](https://reporter.apache.org/). The reporter system should
+send you a reminder email, but in case you miss it, you can add
+the release to https://reporter.apache.org/addrelease.html?datafusion following
+the examples from previous releases.
The release information is used to generate a template for a board report (see
example from Apache Arrow project
[here](https://github.com/apache/arrow/pull/14357)).
-### Delete old RCs and Releases
+### 11: Delete old RCs and Releases
Review Comment:
Inconsistent section numbering: This section is numbered "### 11:" but given
that the previous section should be "### 9:" (not 10), this should be "### 10:"
to maintain sequential numbering.
```suggestion
### 10: Delete old RCs and Releases
```
##########
dev/release/README.md:
##########
@@ -137,119 +198,124 @@ branch-50:
required_approving_review_count: 1
```
-Here are the commands that could be used to prepare the `38.0.0` release:
-
-### Update Version
-
-Checkout the main commit to be released
-
-```shell
-git fetch apache
-git checkout apache/main
-```
-
-Manually update the datafusion version in the root `Cargo.toml` to `38.0.0`.
-
-Run `cargo test` to re-generate some example files:
-
-```shell
-cargo test
-```
-
-Lastly commit the version change:
-
-```shell
-git commit -a -m 'Update version'
-```
-
-## Prepare release candidate artifacts
+### 4. Prepare Release Candidate Artifacts
After the PR gets merged, you are ready to create release artifacts based off
the
merged commit.
(Note you need to be a committer to run these scripts as they upload to the
apache svn distribution servers)
-### Pick a Release Candidate (RC) number
+#### Pick a Release Candidate (RC) number
-Pick numbers in sequential order, with `0` for `rc0`, `1` for `rc1`, etc.
+Pick numbers in sequential order, with `1` for `rc1`, `2` for `rc2`, etc.
-### Create git tag for the release:
+#### Create git Tag for the Release:
While the official release artifacts are signed tarballs and zip files, we also
-tag the commit it was created for convenience and code archaeology.
+tag the commit it was created for convenience and code archaeology. Release
tags
+have the format `<version>` (e.g. `38.0.0`), and release candidates have the
+the format `<version>-rc<rc>` (e.g. `38.0.0-rc0`). See [the list of existing
+tags].
+
+[the list of existing tags]: https://github.com/apache/datafusion/tags
+
+Using a string such as `38.0.0` as the `<version>`, create and push the rc tag
by running these commands:
+
+```shell
+git fetch apache
+git tag <version>-<rc> apache/branch-X # create tag from the release branch
+git push apache <version> # push tag to Github remote
Review Comment:
Documentation issue: The command comment says "create tag from the release
branch" but then pushes `<version>` instead of `<version>-<rc>`. The command
should push the RC tag that was just created. The line should be `git push
apache <version>-<rc>` to match the tag that was created in the previous
command.
```suggestion
git push apache <version>-<rc> # push tag to Github remote
```
##########
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)
+
+Apersonal access token (PAT) is needed for changelog automation script. If you
Review Comment:
Spelling error: "Apersonal" should be "A personal" (missing space between
"A" and "personal").
```suggestion
A personal access token (PAT) is needed for changelog automation script. If
you
```
--
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]
