Automate drafting, verifying, and publishing the release

[adam-christian-software]

Is your feature request related to a problem? Please describe.

A typical Apache Software Foundation release has the following workflow:

1. Draft a release
2. Start a VOTE on the dev mailing list
3. If the VOTE fails, the release has failed - "go to step 1"
4. If the VOTE passes, publish the release

As of this writing (Jul 9, 2025), the process is manual and undocumented. #648 attempts to address the documentation. The Apache Trusted Releases effort (as a part of the larger ASF Tooling Initiative) dictates that all releases should be automated. See https://tooling.apache.org/trusted-release.html for more details. To that end, this ticket proposes automating the mechanisms for the release including automated processes for:

1. Drafting a release
2. Verifying major portions of the release
3. Publishing the release

The benefit of this issue are:

1. Reduce the friction of being a release manager
2. Ensure higher quality for releases through automated verification
3. Ensure less release mistakes by reducing manual steps
4. Enable the project to release more often
5. Allow releases to be created on “trusted instances” rather than user’s computers

Describe the solution you'd like

There are various ways to do the automated release. The major acceptance criteria are:

1. Automated testing as part of the release verification process
2. Failing to publish the release if verification process fails
3. The ability to redraft a release if verification fails or voting fails
4. Drafting, verification, & publishing should all be able to be triggered via a single command
5. Drafting a release notifies the dev mailing list for a vote
6. The automation must have a descriptive README.md that covers the automation framework.
7. The releases should not be built upon a user’s hardware, but only on “trusted instances” (for example, GitHub).
8. A user can verify that the code was built on a “trusted instance”.
9. A user can verify that the code was built from a specific Git commit.
10. A user can verify the code was not modified.
11. A user can verify the code was uploaded by a “trusted instance”. For example, all binaries could be uploaded via a GitHub workflow.
12. In general, the process is public, reproducible, and contains all the information to trust the release.

Describe alternatives you've considered

The team has been working on documenting the manual processes required for release, but this has the issues noted above.

Additional context

Relevant Issues:

1. Document release process and how to verify a release #648
2. Polaris Release Cadence and Roadmap Alignment #584

Relevant Links:

1. https://github.com/apache/polaris/milestones - Milestones for Polaris
2. WIP Release infra stuff #485 - A WIP ideation
3. https://tooling.apache.org/trusted-release.html - The Apache Trusted Release Platform
4. https://www.apache.org/legal/release-policy - Apache Foundation release policy

In addition to this work, there are two other related efforts ongoing:

1. GitHub Workflow for Helm Publishing
2. GitHub Workflow for Docker Images

[jbonofre]

The process is not totally accurate. I will provide more details in a comment regarding the process. For instance it's important to send cancel email to clearly state a rc vote failed etc.

[flyrain]

Here is an existing release guide for reference: https://polaris.apache.org/community/release-guide/