- Ensure that the
main
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
.
- For TinSalver to correctly work with keybase on WSL on Windows, you might need to disable pinentry:
- 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 combined dependency PRs and highlight certain features).
- Rename existing milestone corresponding to new release and close it. Then create a new
next
milestone. - When available through Maven Central, poke Richard North to announce the release on Twitter!
- Merge automated version update PRs in order to update the reference version in
mkdocs.yml
andgradle.properties
.
- 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 uploaded to the Ubuntu keyserver (or other server supported by Sonatype).