adam-christian-software opened a new issue, #2017: URL: https://github.com/apache/polaris/issues/2017
### 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. https://github.com/apache/polaris/issues/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. https://github.com/apache/polaris/issues/648 2. https://github.com/apache/polaris/issues/584 Relevant Links: 1. https://github.com/apache/polaris/milestones - Milestones for Polaris 2. https://github.com/apache/polaris/pull/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 -- 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: issues-unsubscr...@polaris.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
