[Packaging][Release] Create unique git tags for release candidates (e.g. apache-arrow-{MAJOR}.{MINOR}.{PATCH}-rc{RC_NUM})
#41102
Comments
|
take |
|
@raulcd What do you think about this workflow change? |
|
I am happy with it. We might want to add the deletion of old RC tags once we create the tag that has passed the vote. |
sgilmore10
changed the title
dev/release/01-prepare.sh to create release-candidate-specific git tags (apache-arrow-{MAJOR}-{MINOR}-{PATCH}-rc{RC_NUM})apache-arrow-{MAJOR}.{MINOR}.{PATCH}-rc{RC_NUM})
|
I think that we don't need to delete old RC tags. Because there is no limit on the total size of a release: https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases#storage-and-bandwidth-quotas |
sgilmore10
added a commit
that referenced
this issue
Jun 13, 2024
…didates (e.g. apache-arrow-{MAJOR}.{MINOR}.{PATCH}-rc{RC_NUM}) (#41131)
### Rationale for this change
As per @ kou's [suggestion](#40956 (comment)) in #40956, we should create unique git tags (e.g. `apache-arrow-{MAJOR}.{MINOR}.{VERSION}-rc{RC_NUM}`) instead re-using the same git tag (`apache-arrow-{MAJOR}.{MINOR}.{VERSION}`) for each release candidate. The official release candidate tag (`apache-arrow-{MAJOR}.{MINOR}.{VERSION}`) should be created **only** after a release candidate is voted on and accepted. This "official" release tag should point to the same object in the git database as the accepted release candidate tag.
The new release workflow could look like the following:
> 1. Create a apache-arrow-X.Y.Z-rc0 tag for X.Y.Z RC0
> 2. (Found a problem for X.Y.Z RC0)
> 3. Create a apache-arrow-X.Y.Z-rc1 tag for X.Y.Z RC1
> 4. Vote
> 5. Passed
> 6. Create a apache-arrow-X.Y.Z tag from apache-arrow-X.Y.Z-rc1 ike apache/arrow-adbc and apache/arrow-flight-sql-postgresql do
See @ kou's [comment](#40956 (comment)) for more details.
### What changes are included in this PR?
1. Updated `dev/release/01-prepare.sh` to create release-candidate-specific git tags (e.g. `apache-arrow-{MAJOR}.{MINOR}.{PATCH}-rc{RC_NUM}`).
2. Updated scripts in `dev/release` to use the new git tag name.
3. Added GitHub Workflow file `publish_release_candidate.yml`. This workflow is triggered when a release candidate git tag is pushed and creates a Prerelease GitHub Release.
4. Added logic to `dev/release/02-post-binary.sh` to create and push the release git tag (i.e. `apache-arrow-{MAJOR}.{MINOR}.{PATCH}`).
5. Added GitHub Workflow `publish_release.yml`. This workflow is triggered when the release tag is pushed and creates a GitHub Release for the approved release (i.e. the voted upon release).
6. Added `dev/release/post-16-delete-release-candidates.sh` to delete the release candidate git tags and their associated GitHub Releases.
7. Updated `docs/developers/release.rst` with the new steps.
### Are these changes tested?
1. We were not able to verify the changes made to the scripts in `dev/release`. Any suggestions on how we can verify these scripts would be much appreciated :)
2. We did test the new GitHub Workflows (`publish_release_candidate.yml` and `publish_release.yml`) work as intended by pushing git tags to [`mathworks/arrow`](https://github.com/mathworks/arrow).
### Are there any user-facing changes?
No.
### Open Questions
1. We noticed that [apache/arrow-flight-sql-postgresql](https://github.com/apache/arrow-flight-sql-postgresql/releases) does **not** delete the release candidate Prereleases from their GitHub Releases area. Should we be doing the same? Or would it be preferable to just delete the the release candidates **without** deleting the release candidate tags.
2. We're not that familiar with ruby, so we're not sure if the changes we made to `dev/release/02-source-test.rb` make sense.
### Future Directions
1. Continue working on #40956
2. Add logic to auto-sign release artifacts in GitHub Actions Workflows.
* GitHub Issue: #41102
Lead-authored-by: Sarah Gilmore <[email protected]>
Co-authored-by: Sarah Gilmore <[email protected]>
Co-authored-by: Sutou Kouhei <[email protected]>
Signed-off-by: Sarah Gilmore <[email protected]>
|
Issue resolved by pull request 41131 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the enhancement requested
As per @kou's suggestion in #40956, we should create unique git tags (e.g.
apache-arrow-{MAJOR}.{MINOR}.{VERSION}-rc{RC_NUM}) instead re-using the same git tag (apache-arrow-{MAJOR}.{MINOR}.{VERSION}) for each release candidate. The official release candidate tag (apache-arrow-{MAJOR}.{MINOR}.{VERSION}) should be created only after a release candidate is voted on and accepted. This "official" release tag should point to the same object in the git database as the accepted release candidate tag.The new release workflow could look like the following:
See @kou's comment for more details.
Component(s)
Packaging, Release
The text was updated successfully, but these errors were encountered: