Release process

Testcontainers' release process is semi-automated through GitHub Actions. This describes the basic steps for a project member to perform a release.

Steps

Ensure that the master branch is building and that tests are passing.
Create a new release on GitHub. The tag name is used as the version, so please keep the tag name plain (e.g. 1.2.3).
The release triggers a GitHub Action workflow.
Log in to Sonatype to check the staging repository.
- Getting access to Sonatype requires a Sonatype JIRA account and raising an issue, requesting access.
Get the staging URL from Sonatype after GitHub Action workflow finished. The general URL format should be https://oss.sonatype.org/service/local/repositories/$staging-repo-id/content/
Manually test the release with the staging URL as maven repository URL (e.g. critical issues and features).
Run TinSalver from GitHub using npx to sign artifact (see TinSalver README).
- For TinSalver to correctly work with keybase on WSL on Windows, you might need to disable pinentry: keybase config set -b pinentry.disabled true.
Close the release in Sonatype. This will evaluate the release based on given Sonatype rules.
After successful closing, the release button needs to be clicked and afterwards it is automatically synced to Maven Central.
Handcraft and polish some of the release notes (e.g. substitute combinded dependency PRs and highlight certain features).
Rename existing milestone corresponding to new release and close it. Then create a new next milstestone.
When available through Maven Central, poke Richard North to announce the release on Twitter!

The process is done with GitHub Actions, TinSalver and Sonatype.
Sonatype will automatically promote the staging release to Maven Central.
Keybase needs to be installed on the developer machine.
GPG key of signing developer needs to be uplodaed to the Ubuntu keyserver (or other server supported by Sonatype).