Release management

General notes on release building We are encouraged to synchronize the publication of new versions of the IRL close to new Kieker releases. We also want to support multiple Kieker versions with the tool. However, this is not a simple task, because newer records might contain new features which are not supported by older Kieker versions.

Release process

• Fix issues relevant for the next Kieker release
• Two week prior to the Kieker release, create a release branch $BRANCH, e.g., 'rel-1.1.0'

git checkout -b $BRANCH

• Push the release branch

git push origin $BRANCH

• Change in the Jenkins build project Kieker-IRL-Release the 'Branches to build' to the new release 'origin/$BRANCH', e.g., 'origin/rel-1.1.0'
• Update all files in the branch which define the new release verion, including pom.xml and 'plugin.*'. This can be done with which utilizes the 'pom.xml.template' files. However, it is be necessary to check the templates for correctness before running the script, as new dependencies might have been added.

de.cau.cs.se.instrumentation.releng/scripts/set-release-properties.sh 1.1.0 1.1.0 release/1.1

• Make a local check build with

mvn clean compile

• Commit and push changes to the release branch. Use a meaningful commit message.

git commit -a

git push

• Run the Kieker-IRL-Release project
• Copy the built command line compiler to Kieker
• One week before Kieker release, copy the final IRL compiler to Kieker
• Check if it builds ok.
• Check if the update site release has been produced
• Tag this final $BRANCH revision rel-1.1.0-final
• Merge back any fixes to master, be aware that you changed pom.xml and other files version id
• Setup the 'pom.xml' for the next snapshot version in the master branch by running the script again

de.cau.cs.se.instrumentation.releng/scripts/set-release-properties.sh 1.2.0-SNAPSHOT 1.2.0.qualifier snapshot