Hi Robert Thanks for this !
I will take a look at the script, but the overall process looks good to me. In order to use "comparison" (in the outputs), I propose: 1. To do 0.9.0 "manually", as I already started(I created https://github.com/apache/polaris/pull/495 to fix what we need for the 0.9.0-incubating-rc2, I still have to include LICENSE.bin in polaris-service distribution) 2. After review and 0.9.0-incabuting release, merge release script on main I hope to have time to review during the weekend. Regards JB On Thu, Nov 28, 2024 at 10:27 AM Robert Stupp <sn...@snazy.de> wrote: > > Hi all, > > (Sorry, big topic...) > > In this [1] draft pull request I have started a way to > semi-automatically do releases, following the Apache rules (draft RC -> > vote -> publish -> announce). It is intended to be run in Github actions > and handles all the various manual steps, which can be time consuming > and are not that easy to get right all the time. > > Building releases is in general a sensitive task that should be > performed in a separate environment in a reproducible way. Doing > releases in Github workflows and is a suitable environment for releases. > The necessary secrets (credentials for GPG, dist.apache.org, Apache > Sonatype and later for container registries) are only needed by the > release related workflows. It also makes it easier for non-(P)PMC > members to do releases. > > While the scripts in the mentioned PR are intended to be run in GH > workflows, those can also be run locally for development and testing > purposes. Local runs do intentionally not touch Apache's Sonatype nor > dist.apache.org (SVN is simulated using local SVN repos, so the only > difference is the checkout location). > > The "Git logic" is based on the principle to _not_ touch (change/push > to) the 'main' branch (or a version branch). This is quite important for > multiple reasons: > * Doing releases based on a specific commit that's not the "head" of a > branch > * Relying on pushes to the source branch from the release process can > easily race w/ concurrent commits/merges and let the release process fail > > Instead, the release script(s) create a new commit with the necessary > changes (version.txt, generated release notes and some release meta > information) and creates a Git tag on that one. As an example: > > O <-- Git tag 'apache-polaris-1.2.3-rc1' > / > ---O---O---O---O--- <-- 'main' branch (or some version branch like > polaris-1.2) > > Once the release has been drafted (all artifacts pushed/staged, the > RC-commit/tag has been created and pushed, vote email proposal > generated), the release vote can happen. If the vote fails, a new RC can > be created - the scripts take care of incrementing the RC number > (iteration). If the vote passes, the release can be published. > Publishing means that the Sonatype staging repository is released (Maven > artifacts published), a release Git tag is added to the RC Git tag (e.g. > 'apache-polaris-1.2.3' - without the '-rcX' suffix), the source tarball > files are "moved" to the releases-SVN, website updated with the new > release, announcement-email proposal generated. > > All scripts have some help and validation and runtime check logic. This > covers things like: > * The Git worktree must not be dirty > * Cannot create a draft (RC) for an already released version > * Cannot publish an already released version > * Automatically add the "-incubating" suffix to the version > (conditional, checks the "podling" status in whimsy.apache.org) > But also: > * Automatically increment the patch version - for example trying to a > version 1.2 release and 1.2.3 has already been released (Git tag > exists), an 1.2.4-rc1 will be created > * Automatically increment RC iteration (latest Git tag for a 1.2 release > is already an RC) - is is the case when a release vote failed > > Noteworthy: > * The (previous) content of the version.txt file does not matter. The > release scripts overwrite the file with the "correct" version. > * The Git tags do not have the "-incubating" suffix, because that makes > handling the Git tags overly complex - especially when becoming a TLP. > The version itself however gets the "-incubating" suffix > > How the scripts are actually invoked in production: > * releases/bin/draft-release.sh --major 2 --minor 4 > * releases/bin/publish-release.sh --major 2 --minor 4 > > For local tests, start with adding the '--dry-run' option. When trying > it out without the '--dry-run' option, make sure your local > 'versioned-docs' branch does NOT have 'apache/polaris' as its Git > upstream (publish-release.sh would push to it!). Also note that > artifacts will be signed, so you need to have gpg setup (uses the gpg > agent locally). > > > The release notes are generated from two major sources as markdown: > * Git commits between the previous version and the released version > * Contents of the (new) NEXT_RELEASE_NOTES.md file > The generated release notes start with a "thank you" to the contributors > for that release, followed by the content of the NEXT_RELEASE_NOTES.md > (if not empty) and the Git commits (subject, author and body), which are > enriched with links to GitHub (PR + commit) > > > Sorry for the wall of text, > > Robert > > > PS: On top of the actual release scripts, there are also scripts to > handle version branches like 1.x, 1.0.x - those are not necessary for > the release process though. > > > [1] https://github.com/apache/polaris/pull/485 > > -- > Robert Stupp > @snazy >
