Maintainer Guidelines

Release process

This describes the release process.
There is no specific release schedule - fixing a bug or implementing features which are
ready for release may be released without further hesitation.

We use semantic versioning like in MAJOR.MINOR.PATCH, where we increment:

1. MAJOR update with incompatible API changes
2. MINOR features added in a backwards compatible manner
3. PATCH bug fixes in a backwards compatible

Commit: Prepare for release

1. Checkout a new release branch

2. Bump the version in README.md and update its section CHANGELOG

3. you may want to update library dependencies in pom.xml

4. do a signed commit and add commit message

   Prepare for release

   Signed-off-by: $yourIdentity

Commit: Release

Remove the "SNAPSHOT" from pom.xml and core/pom.xml and do a signed commit. This last commit of the new release shall be tagged (note the v prefix) and also signed:
git tag -s v${MAJOR.MINOR.PATCH} with the commit message:

Release ${MAJOR.MINOR.PATCH}

Signed-off-by: $yourIdentity

Tag and push into master

Get the release branch into master.
Check if the new tag is already propagated into the remote repository:
git ls-remote --tags origin. If not, do it now:
git push origin v${MAJOR.MINOR.PATCH}

Uploading to Sonatype

mvn clean deploy -Psonatype-oss-release
Log into https://oss.sonatype.org/, check the Staging Repositories when it's finished,
and release it to maven central: click Close, wait until it's build, and click Release.

Bump to next development version

Increase the PATCH number and append "-SNAPSHOT" in core/pom.xml and pom.xml.
Push to master.