Releasing Apache Taverna

Anyone in the Apache Taverna community can propose a release, although usually a release is prepared by one of the committers. This page describes the procedure for preparing and voting over a release.

Release early, release often


Jira updates

Check the Jira versions have a corresponding version for the release you are preparing, and a new version for the following development version. E.g. you are preparing the release candidate taverna-language 0.15.1, so make sure language 0.15.1 exists, and create language 0.16.0 for the next development. You should also check that the earlier published version is marked as Published in Jira - you may need to find the Published date by looking in the email archives.

Go through the open issues for the components you are preparing to release, e.g. Unresolved for Taverna Maven Parent - close those that are done, and reschedule Fix Version to a later version if their "Fix Version" is set to the one you are preparing (or earlier).

Now go through issues that are resolved since the previous release (e.g. Done/In Review Taverna Language issues with Fix For No/Unreleased ), and set their Fix version to your release candidate version, so that they will appear in the generated Release notes (click Configure Release Notes).

Prepare your build machine

You need to build and release Apache Taverna from a machine you have control over. Make sure you have a recent version of java and mvn:

stain@biggie-utopic:~/src/taverna$ java -version
openjdk version "1.8.0_45-internal"
OpenJDK Runtime Environment (build 1.8.0_45-internal-b14)
OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode)

stain@biggie-utopic:~/src/taverna$ mvn -version
Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c; 2015-03-13T20:10:27+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_45-internal, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "3.19.0-18-generic", arch: "amd64", family: "unix"

Then let's have a clean Maven Repository to ensure the build works out of the box.

cd ~/.m2/
mv repository repository-old
rm -rf repository-old &

Similarly we'll use a fresh check out from git to a new folder, to ensure uncommitted files are not being included in the release. For the examples below, we'll create and use ~/src/rc1 as the working directory.

mkdir rc1
cd rc1

GPG keys

You need to have gpg and preferably a GPG Agent installed on the machine you will build the release on. This needs to be configured with your GPG release key.

Check that the Apache Taverna KEYS file contains your correct key and fingerprint. If not, then:

Find your PGP fingerprint:

stain@biggie-utopic:~/src/rc1/dist$ gpg --fingerprint
pub   1024D/A0FFD119 2002-01-20
Key fingerprint = DDDE E876 12E9 FB95 F5C8  D91E 4110 63A3 A0FF D119
uid                  Stian Soiland-Reyes <>
uid                  Stian Soiland <>
uid                  Stian Soiland <>
uid                  Stian Soiland <>
uid                  [jpeg image of size 9477]
uid                  Stian Soiland <>
uid                  Stian Soiland-Reyes <>
uid                  Stian Soiland-Reyes <>
sub   4096R/4BBAC7C6 2014-06-05 [expires: 2016-06-10]

Edit your details on to provide your OpenPGP Public Key Primary Fingerprint, e.g.:

DDDE E876 12E9 FB95 F5C8  D91E 4110 63A3 A0FF D119

Check your key has not expired - you can use gpg --edit-key and gpg --send-key to update.

Now verify that the taverna.asc file now includes the correct key fingerprint, and update on dist:

svn co
cd taverna
cat KEYS.template taverna.asc > KEYS
rm taverna.asc  
svn commit -m "Updated KEYS" KEYS

Fresh checkouts

Then we'll clone the Taverna git repositories that we are going to release. Be sure to clone using the Apache Committer URLs, as found on the /download/code/ page:

git clone
git clone

Note that you do not need to clone the repositories which are already released and which don't form part of this release.

Git config

Make sure that each new checkout have the correct user name information and your email address, as the Maven Release plugin will be doing the tagging on your behalf.

cd incubator-taverna-maven-parent
git config "Your Name"
git config

cd ../incubator-taverna-language
git config "Your Name"
git config

Verify build

Now we'll make sure they build normally, pass all the tests and complete with BUILD SUCCESS:

mvn clean verify

Note that this would download all the dependencies from Maven Central.

Maven repository access

When releasing a stable version, Maven will deploy to Apache's Maven repository, a Nexus instance. Here, a staging repository will be automatically created.

Ensure you can log in to the Nexus instance before performing a release.

To provide the Nexus credentials, edit your ~/.m2/settings.xml to include your committer credentials for the servers apache.snapshots.https and apache.releases.https:

<?xml version="1.0" encoding="UTF-8"?>
<settings xsi:schemaLocation="" xmlns=""

To check you have the correct credentials set up for write-access to Apache's Maven repository, deploy the current SNAPSHOT:

mvn deploy

This is best tested with a small repository like taverna-maven-parent as it will perform a build.

Closing old staging repositories

Check the list of open Staging Repositories on the Nexus instance, and Close/Drop any old orgapachetaverna-* repositories. Do not touch the other repositories from other projects.

Creating release candidate

Figure out release order

If more than one git repository needs to be released, e.g. because the newer SNAPSHOT version is needed, then those repositories needs to be released in incremental order. The dependency order is generally from top to bottom of the list on the code download page, e.g. taverna-language before taverna-engine before taverna-workbench.

Fix versions

Edit the top-level pom.xml of each project to release, ensuring there are no -SNAPSHOT dependencies in its <parent> and <properties>.

Do not fix the <version> of the Maven project itself or its submodules, as they must be on the form *-SNAPSHOT in order for the Maven Release Plugin to modify them.

Check if a newer apache-taverna-maven-parent or other taverna.*.version dependencies are needed. This is usually indicated by depending on an unreleased -SNAPSHOT version. Accordingly, after the release process, do not update master to use the bumped SNAPSHOT versions, as that would wrongly indicate that a newer dependency is needed. (After the release you should change the master branch pom.xml so that the <properties> and <parent> use the current public release (not the release candidate, as it is not yet public).)

For compile/test purposes, update all taverna.*.version properties to the latest released version - or the staging version if you need to depend on a release candidate version that is being prepared together with this one.

Exception to the rule: - when OSGi backwards-compatibility is needed, e.g. an updated wsdl-activity that should work also with an older taverna-engine-api release.

Remember that in OSGi, as long as we follow semantic versioning and don't break API compatibility, an upstream dependency can be updated without forcing an update release of its downstream users.

If you are updating apache-taverna-maven-parent, then try to update this to use the latest version of the Apache super-pom - be aware that this could change Maven build settings.

Commit your pom.xml changes (if any) and push.

git commit -m "Dependency updates for release 1.2.3" pom.xml
git push

Prepare release candidate

We use the Maven release plugin to release candidates as it ensures a consistent release process:

mvn release:prepare -DautoVersionSubmodules=true

Note: Maven will use gpg multiple times to tag and sign the artifacts - so you might want to install and configure a GPG Agent to avoid repeatedly providing your GPG passphrase.

The defaults for "What is the release version for" is usually good (assuming the SNAPSHOT version has been correctly bumped for any major/minor/patch changes to the code), but check the policy for version numbers below.

[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for "Apache Taverna Language APIs (Scufl2, Databundle)"? (org.apache.taverna.language:taverna-language) 0.15.0-incubating: :
What is the release version for "Apache Taverna Baclava support"? (org.apache.taverna.language:taverna-baclava-language) 0.15.0-incubating: :
What is the release version for "Apache Taverna Scufl 2 UCF Package"? (org.apache.taverna.language:taverna-scufl2-ucfpackage) 0.15.0-incubating: :
What is the release version for "Apache Taverna Scufl 2 API"? (org.apache.taverna.language:taverna-scufl2-api) 0.15.0-incubating: :

If you do not include -DautoVersionSubmodules=true you will be asked for each submodule what version they should have - generally their version should be the same as their parent (except to explicitly allow API backward compatibility).

Note: Take care to use the correct version number if preparing a second release candidate, as Maven could suggest a higher version number based on the bumped -SNAPSHOT version.

Important: If Maven prompts for the new development parent version remember to set it back to the previous *-incubating-SNAPSHOT (where `*`` is what is now in the parent pom). The reason for this is that the taverna-maven-parent release candidate will remain in the staging repository and can't be used by developers until it is released - and if you bump this to the next SNAPSHOT version early, then other modules that may rely on the previous SNAPSHOT will stop working as the Nexus repository wipes older SNAPSHOTS regularly - and this could break Jenkins builds and developer builds. (Too late? You can always fix this manually in the pom and commit manually after the release has been performed/deployed.)

Version numbers

Semantic versioning summary:

Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards-compatible manner, and
  • PATCH version when you make backwards-compatible bug fixes.

Use git diff against the previous release tag for a rough check for changes.

git diff 0.15.0-incubating-RC2

Note that as we use of OSGi, the public Java API is usually just what is exposed by the *-api modules, meaning that implementation changes normally should just warrant a new patch version. We should also consider indirect APIs, such as an Activity's expected JSON configuration or the REST API of the Taverna Server.

Check with dev@taverna if you are not sure. Usually bumping minor (e.g. from 1.5.2 to 1.6.0) is the right option, as we release all modules in the git repository.

Tagging and next SNAPSHOT version

For the tag, use the proposed format (0.15.0-incubating-RC1), but modify -RC1 for any subsequent release candidates.

What is SCM release tag or label for "Apache Taverna Language APIs (Scufl2, Databundle)"? (org.apache.taverna.language:taverna-language) 0.15.0-incubating-RC1: :

Module-specific release: If a hot-patch update of a particular Maven module is being released from within its subfolder, then prefix the tag-name with the module name, e.g. taverna-scufl2-t2flow-0.15.1-incubating-RC1. Note that preparing a single module release requires careful consideration for setting the <parent> and <dependency> versions and should generally be avoided.

The next development version should usually be one patch version higher, or for taverna-maven-parent simply the next number:

What is the new development version for "Apache Taverna Language APIs (Scufl2, Databundle)"? (org.apache.taverna.language:taverna-language) 0.15.1-incubating-SNAPSHOT: :
What is the new development version for "Apache Taverna Baclava support"? (org.apache.taverna.language:taverna-baclava-language) 0.15.1-incubating-SNAPSHOT: :
What is the new development version for "Apache Taverna Scufl 2 UCF Package"? (org.apache.taverna.language:taverna-scufl2-ucfpackage) 0.15.1-incubating-SNAPSHOT: :
What is the new development version for "Apache Taverna Scufl 2 API"? (org.apache.taverna.language:taverna-scufl2-api) 0.15.1-incubating-SNAPSHOT: :

Maven will now transform your poms, create the tag, and push changes back to Apache's git repository.

If you abort, you can start the process again using mvn release:prepare, which will pick up your answers so far from the file release.profiles.

Rolling back

If anything goes wrong at this stage, you will need to undo, edit and commit required changes, and start again:

mvn release:rollback
vi foo/pom.xml
git commit
git push
mvn release:prepare

Deploying the release candidate

If the preparation was successful, then you should now be able to do:

mvn release:perform

This will check out the tag, build it, then sign and deploy the packaged source code and compiled JARs to

Locate the staging repository

On Apache's Nexus instance, locate the Staging Repository for the code you just released. It should be called something like orgapachetaverna-1001 -- check the Updated time stamp and click to verify its Content.

You can leave the staging repository Open until you have released all the projects that will form part of this [VOTE], e.g. you can deploy both taverna-maven-parent and taverna-language using the same staging repository.

Important - When all artifacts to be deployed are in the staging repository, tick the box next to it and click Close.

DO NOT CLICK RELEASE YET - the release candidate must pass [VOTE] emails on both dev@taverna and general@incubator before we release.

Once closing has finished (check with Refresh), browse to the URL of the staging repository which should be something like

Uploading to

The release candidate source code, checksums and signatures should be uploaded to the dev area of using svn - which we'll check out to a new folder ~/src/rc1/dist:

svn co dist

The source folder of dev should normally be empty -- if you find remains of an earlier RC that is not still under [VOTE], first remove them with svn rm:

cd dist/source
svn rm *

Now go back to the dist directory. Retrieve the source archives from the staging repository by looking for -* (not sources.jar!) in the staging repository, located under the folder corresponding to the groupID and artifactId of the top-level project, e.g. org/apache/taverna/language/0.15.0-incubating/ containing

For consistency checking you also need to include the PGP signature .asc and the checksums .sha1 and .md5

Here's a convenient wget command to get all the release archives, their checksums and signatures:

wget -e robots=off --recursive --no-parent --no-directories -A "*-source-release*"

Make sure you have not got any extra files in your dist/ folders, like index.html or duplicates like *.zip.1. You can delete any files ending in .asc.md5.

stain@biggie-utopic:~/src/rc1/dist$  ls
binaries/ source/

Under source/, make a corresponding versioned folder for each product, and include the RC number, avoiding confusion in case you need to make a second release candidate:

mkdir source/taverna-language-0.15.0-incubating-RC2
mkdir source/taverna-parent-1-incubating-RC2
mv *language*release* source/taverna-language-0.15.0-incubating-RC2
mv *parent*release* source/taverna-parent-1-incubating-RC2

Now add them to the source folder with svn add and svn commit

svn add taverna-language-0.15.0-incubating-RC1 taverna-parent-1-incubating-RC1
svn commit -m "taverna-language 0.15.0-incubating-RC1"

If any binary distributions are also be provided from the Download page (e.g. Taverna Workbench installers and Taverna Server wars), then download them as well from the staging repository and add them under equivalent versioned folders in binaries/, including their corresponding .asc, .md5 and .sha1 files,

Versioned folders make it easier to tidy up after a dropped release candidate, and easier to promote the release.

Now verify that the files are available on - you might need a Refresh in the browser.


Any Apache release must be approved through a vote of the project's PMC. As Apache Taverna is an incubating project, a Taverna release must be approved by both the Apache Taverna PPMC followed by the Apache Incubator IPMC.

Before an Apache Taverna release can be distributed, it must thus pass two stages:

Each of the [VOTE] threads should be open for at least 72 hours, allowing time for sufficient review, and catering for differences in holidays and timezones.

Including 24 hours grace period for the download mirrors to update, this means a release takes a minimum of a week before a release candidate might be published and released.

Anyone in the community can participate in the review and vote, not just PMC members or committers. Only votes from IPMC members (e.g. our mentors) are binding.

Vote email to dev@taverna

To start the release vote, modify the below example and send to dev@taverna. Remember [VOTE] in the subject line and change the version number to match the release candidate.

``` Subject: [VOTE] Release Apache Taverna Language 0.15.0-incubating RC2

I am pleased to be calling this vote for the source release of

Apache Taverna Maven Parent 1-incubating Apache Taverna Language 0.15.0-incubating

To discuss this release candidate, use the corresponding [DISCUSS] thread.

Apache Taverna Language is a set of APIs for workflow definitions (SCUFL2) and workflow inputs/outputs/run (DataBundle), as consumed and produced by the Apache Taverna workflow system. The API includes support for working with Research Object Bundles, and loading/saving Taverna workflows in different formats.

The release candidates to be voted over are available at:

SHA-1 checksums: 8199880048a59cde622e0caa24c3bc3d83bc5d5a 7032e9d2be834f7c029aae562b62613481bf6939

MD5 checksums: 7f9b107b9f1dc0407783ac0ad484d6ea 35d3085b596b2dd4b30a0234259efade

Build the release candidate in the above order, using:

mvn clean install

The release candidates correspond to the following git commits:;a=commit;h=3ba669c78782d3fc3b548e2a512d201ee922b34a;a=commit;h=3340e2090e604b40ac0b88675f57c1d12032d060

Release candidates are signed with a GPG key available at:

A staged Maven repository is available for review at:

The changelog for this release is available from JIRA:

Please vote on releasing these packages as:

Apache Taverna Maven Parent 1-incubating Apache Taverna Language 0.1.0-incubating

The vote is open for at least 72 hours and passes if a majority of at least three +1 Apache Taverna PPMC votes are cast.

[ ] +1 Release this package [ ] 0 I don't feel strongly about it, but don't object [ ] -1 Do not release this package because...

Anyone can participate in testing and voting, not just committers, please feel free to try out the release candidate and provide your votes. ```

Discuss email to dev@taverna

It is also recommended to start the discussion around the release candidate with a separate thread with subject

[DISCUSS]: Release Apache Taverna Language 0.15.0-incubating RC2

Remember to change the version number as appropriate for the release candidate.

Tip: Do not use the "Reply to All" button from the [VOTE] email to create the [DISCUSS] thread - as then they would still appear as a single thread due to the In-Reply-To email header.

Tallying the vote

After at least 72 hours, count the votes in the [VOTE] thread. You need to count separately the binding votes from mentors, as these can carry over to the general@incubator vote.

You can find URLs for individual emails (e.g. the binding votes) in the dev@taverna archive by clicking a message and then clicking Permalink. Note that the email archive may be slow to update.

To close the vote thread, send a [RESULT][VOTE] email to dev@taverna, e.g.

``` Subject: [RESULT][VOTE] Release Apache Taverna Parent 1-incubating-RC4 & Apache Taverna Language 0.15.0-incubating RC4

Voting for Apache Taverna Parent 1-incubating & Apache Taverna Language 0.15.0-incubating is now closed. The release has passed with the following tally:

Binding +1s:

Marlon Pierce (see

Andy Seaborne (see

Non binding +1s:

Ian Dunlop Alan Williams Stian Soiland-Reyes Donal K. Fellows ```

If the vote has not passed (at least +3, or more negative than positive) then you will need to pull the release candidate and start over after addressing the concerns.

If there are any -1 or 0 votes, then those concerns should be addressed. Often it can be sufficient to just track these in Jira as scheduled for the next release - while other times the concern could be grave enough to pull the release (e.g. doesn't compile).

Vote email to general@incubator

Using the tally count, now you can send another [VOTE] email to the general@incubator list (which you must be subscribed to):

``` Subject: [VOTE] Release Apache Taverna Parent 1-incubating-RC4 & Apache Taverna Language 0.15.0-incubating RC4

The Apache Taverna Incubator PPMC has voted +5 to release

Apache Taverna Parent 1-incubating (RC4) Apache Taverna Language 0.15.0-incubating (RC4)

Incubator PMC members please review and vote on this incubator release.

Apache Taverna Language is a set of APIs for workflow definitions (SCUFL2) and workflow inputs/outputs/run (DataBundle), as consumed and produced by the Apache Taverna workflow system. The API includes support for working with Research Object Bundles, and loading/saving Taverna workflows in different formats.

Please see original [VOTE] thread

and [DISCUSS] thread

The release candidates to be voted over are available at:

(.. copy the download/test details from previous email)

Please vote on releasing these packages as:

Apache Taverna Maven Parent 1-incubating Apache Taverna Language 0.15.0-incubating

The vote will be open for a minimum of 72 hours.

[ ] +1 Release this package [ ] 0 I don't feel strongly about it, but don't object [ ] -1 Do not release this package because... ```

Dropping a release candidate

If a release candidate is to be dropped, e.g. it fails the [VOTE], then:

In Nexus, tick the staging repository and Drop.

Delete the old tag:

git push origin :0.15.0-incubating-RC1

Roll back the SNAPSHOT version number:

mvn release:update-versions -DautoVersionSubmodules=true -DdevelopmentVersion=0.15.0-incubating-SNAPSHOT`

In your dist checkout, svn rm the dropped RC folders:

svn rm *RC*

Raise Jira issues for the reasons that caused the RC to be dropped.


Once a [VOTE] [Results] email has been agreed on general@incubator, then:

Moving to release area

Use full URL svn mv to move the accepted release candidate to the release folder structure on, e.g. at but remember to remove the -RC1 part from the folder name.

svn mv -m "Releasing apache taverna-language-0.15.0-incubating"
svn mv -m "Releasing apache taverna-parent-1-incubating"

Releasing Maven repository

Tick the correct staging repository (perhaps do a quick check of an SHA1 sum against the vote email), then click Release. It should then propagate to Apache's release Maven repository and eventually mirrored to Maven Central.

Update download page

Wait 24 hours for the download mirrors to pick up the new release from, otherwise eager users (or users who just happened to want to download that day) may get 404 Not Found errors.

Update (or make) the corresponding pages under including the correct version number for the Maven dependencies and the release dates.

Download links should be using the mirror redirector, e.g.

The asc/md5/sha1 links should go directly to - e.g. (important bit: https)

Removing old versions

After the download page has been published, the download mirrors have synchronized and the new version is live you must remove the old versions from

svn rm
svn rm

Older versions are archived under but won't appear on the download mirrors.