Release Management
Before you do any release related action, you should definitely read the release sections on the Apache website and the incubator release management pages.
The Apache Stanbol release management process is very similar to the one followed by the Apache Sling project. Their release management documentation is a must read for Apache Stanbol committers.
Apache Stanbol is a modular software stack and therefore all of its modules basically have different release cycles. So each component of Apache Stanbol may be released independently of others. The only requirement is, that a released Apache Stanbol component may not have any SNAPSHOT dependencies to any other component it depends on.
To release a single component, Apache Stanbol makes use the Maven Release plugin. This plugin takes care of checking that there are no SNAPSHOT dependencies left. Additionally, there are some checks for legal issues automatically performed using the Apache RAT Maven plugin.
To do a release test build, you have to activate the 'apache-release' profile, like it is done in this command:
$ mvn install -Papache-release
The 'apache-release' profile will be automatically activated when the Maven Release plugin is used. For staging an official release with signing the released artifact, making SVN tags, and uploading the artifact to the staging repository.
To start a release we use the following command. We ensure that 'clean install' is executed first. Then we adjust the commit comment that will be generated by the release plugin.
Our goal is to cut the release and leave the current trunk untouched as it was before. We will update versions after the release vote has passed -- not before. That means that the values that you enter when asked for the next development version should be the same development version as it was before.
$ mvn release:prepare -DpreparationGoals=clean install \ -DupdateDependencies=false \ -DscmCommentPrefix=STANBOL-XXX:
Please, replace the XXX with the corresponding Jira issue number.
After the release was prepared and tags created, the release has to be staged. This is done by executing the following command.
$ mvn release:perform -DreleaseProfiles=apache-release -DscmCommentPrefix=STANBOL-XXX:
For further information we refer to the Apache Sling website and their very good documentation of doing a release.
Tips & Tricks
Here are some tips and tricks of commands that are useful, e.g. when examing the code base before a release.
Determine SNAPSHOT dependencies
If you want to release a component, e.g. the Entity Hub, you have to know all used SNAPSHOT dependencies. We are especially interested in internal dependencies to other Apache Stanbol components. On a Unix system something like this could be used:
$ mvn dependency:tree | grep \\-SNAPSHOT | sed s/.*org/org/ | sort -u
Update version of parent POM
The parent POM got released and now we have to update to the new version in all artifacts. The Versions Maven Plugin can help here. Is has a separate goal to update the parent POM. The plugin searches in the local Maven repository for the latest available version of the parent POM and updates all POMs to this version. When executing this goal the parent POM itself must not be part of the build. So maybe you have to edit the top level reactor POM first. The used command looks as follows.
$ mvn versions:update-parent -DgenerateBackupPoms=false -DallowSnapshots=true
If you want to update to the latest non-SNAPSHOT version, you have to set 'allowSnapshots' to 'false' (default). A backup of the changed POMs is not needed when files are under SVN control. To revert any local changes, you could use
$ svn revert -R *
Exclude files from check for modifcations
When you use
$ mvn release:prepare
it will check for local modifications. If you want to exclude some files from this check, e.g. a RAT report file named "rat.txt", you can do it like this
$ mvn release:prepare -DcheckModificationExcludeList=rat.txt
Change the comment when creating commiting changes
The default commit comment starts with "[maven-release-plugin]" when using the Maven Release Plugin. You can change this and e.g. set it to a Stanbol Jira issue number.
$ mvn release:prepare -DscmCommentPrefix=STANBOL-XXX: