(Still catching up on emails after being a couple days off)
I've got some code as an experiment [1] to automate most of the work for releases based on the Hugo-website branch. It's not quite in the state to open a PR yet, and it's just one possible approach. What it can do so far:
1. Draft a release (create an RC) - basically automating all the "boring manual work" before a release-vote can start: update the version.txt file, memoize the Sonatype staging-repository-ID, upload the source-tarball to SVN (still a TODO) - finally commit all that to a new Git tag (e.g. polaris-1.2.3-RC3). Then provide a template for the release vote email (copy-paste needed here). 2. Publish a release (when the vote has passed) - basically automating all the "boring manual work" to publish the release: Create the release-Git-tag (e.g. polaris-1.2.3) from the RC Git tag, Release the Sonatype staging repository, update the versioned docs (Hugo based web site), create a release on GitHub.
A bunch of guardrails and helper code is already there - e.g. prevent creation of an RC after a release, automatically increment RC numbers, having multiple RCs for different major/minor versions.
The scripts can optionally also help manage version branches for future patch releases (think: a polaris-1.5.x branch) and minor version branches (think: a polaris-1.x branch for 1.1, 1.2, 1.3, etc releases).
The part that needs consensus though is _how_ we want to do versioning / branching. I went with that 999-SNAPSHOT version, because that doesn't require any RC release tooling to commit and push commit(s) to any source branch (e.g. the "main" branch). That's "better", because if some GitHub workflow does need to commit and push, it can easily run into a Git conflict and in turn easily fail the whole release.
The release-version docs would be pushed to a different branch, which is just for the versioned docs, which would only be modified by that GitHub workflow (so no risk of a Git race/conflict).
It's all meant to eventually run in GitHub workflows - but there's a dry-run option that simulates what _would_ happen.
Happy to talk more about this during our first community sync and gather your opinions!
[1] https://github.com/snazy/polaris/tree/releases-infra/releases On 23.09.24 19:21, Jean-Baptiste Onofré wrote:
Hi folks, As we know from experience, that the first release needs some careful preparation steps, I would like to propose aiming for the Apache Polaris release by the end of October (after CoC NA). I propose to start from 0.1-incubating (currently we are building 999-SNAPSHOT :) ). I already created 0.1 milestone on GitHub. We can rename it if needed. The preparation steps would be: - do the triage on the GitHub issues, assigning issues to the 0.1 milestone - check the legal (LICENSE, NOTICE, DISCLAIMER, KEYS, etc). I will start some new checks/updates on that (as I have some experience :) ). - check distribution and artifact publication (dist.apache.org, repository.apache.org, ...) I have several PRs in preparation, including the release preparation related PRs. As reminder about the process (https://incubator.apache.org/guides/releasemanagement.html), we need to do release "internally" to the podling , and then start "again" the vote on the incubator general mailing list. So it's a "longer" process comparing to a TLP release. What do you think ? Thanks, Regards JB
-- Robert Stupp @snazy
