Performing a LearnLib Release

This howto will guide you through the process of creating a release of LearnLib using Maven Release Plugin.

Prerequisites

You need:

• a Sonatype account (to create one, visit https://issues.sonatype.org/)
• developer rights for the de.learnlib group at Sonatype OSSRH (contact Markus Frohme or Malte Isberner for this purpose)
• an installed and correctly configured GPG command line client
• GPG keys and have your public key uploaded to hkp://pool.sks-keyservers.net/ (see instructions)

Assumptions

For this howto, we make the following assumptions:

• you are performing a regular (i.e., non-qualified) release. In case the release is qualified (e.g, 0.9.1-ase2013-tutorial), please do not use the release branch, but substitute release with some dedicated branch for this qualifier
• the current version on the release branch is 1.2.3-SNAPSHOT and you want to release version 1.2.3
• all changes are committed and pushed to the release branch. If you want to perform a new major/minor release, you may want to merge the develop branch beforehand.

Process Walkthrough

Step 1: Perform the release

git checkout release
mvn release:clean release:prepare release:perform

You will be prompted for:

• the release version: depending whether the next version should be a bugfix/minor/major release, choose 1.2.3, 1.3.0 or 2.0.0
• the SCM tag: this should be preconfigured to follow the intended pattern learnlib-1.2.3
• the next development version: this is a SNAPSHOT version, either 1.2.4-SNAPSHOT, 1.3.0-SNAPSHOT or 2.0.0-SNAPSHOT, depending on whether this is a bugfix, minor or major development iteration. When performing a bugfix release, we usually choose the version of the develop branch to minimize interference when reintegrating the changes (See Step 2).
• your GPG passphrase

Step 2: Synchronize other branches (for non-qualified releases)

In order to synchronize the changes of the release with the other branches, you need to merge certain commits of the release branch back to the other branches (see Branching Model).

Note: this only holds for non-qualified releases. If the release version has a qualifier (e.g., 0.9.1-ase2013-tutorial), a dedicated release branch (e.g., named ase2013-tutorial-release) should be created and used for the release and should not be merged back to the develop branch.

• merge the tag into the master branch:

git checkout master
git merge learnlib-1.2.3 --ff-only

• merge the release HEAD into the develop branch:

git checkout develop
git merge release

During the build the project documentation and JavaDoc is automatically generated into a local checkout of the gh-pages branch. In order to update the github pages, one has to

• add the new documentation,
• update the reference to the latest documentation and
• update the list of the available documentation.

cd $REPO/target/checkout/target/scmpublish-checkout/maven-site
git add 1.2.3
unlink latest
ln -s 1.2.3 latest
vim index.html
git ci -am "1.2.3 release"
git push

Step 3: Promote the release

1. Open the Nexus UI at https://oss.sonatype.org/ and log in
2. Under Build Promotion, click on Staging repositories
3. In the list, select the staging repository (delearnlib-xxxx), where xxxx is some number (usually 1001)
4. Click "Close" (you will be prompted for a comment). Closing can take some time. You can refresh regularly, but you will also receive an e-mail notification once the repository is closed.
5. Once the repository appears with status "closed", select it and click "Release" (you will again be prompted for a comment).

If everything went well, the artifacts should be synced to Maven Central within the next two hours.