Skip to end of metadata
Go to start of metadata

Code freeze

After code freeze, when myGrid are finalizing a new version of Taverna Workbench for release, the release manager (traditionally Alan or Stian) will create a build branch which Hudson will be building as a new build target for that particular target version.

This build would link to the deployed tagged versions of modules which are not updated in that particular build, but these would be disabled in the phantom POM file, to avoid building and re-deploying new binaries. Instead these modules will be picked up from the Maven repository, where they were deployed by the previous release.

The SVN externals for the 'new' modules which versions have not yet been deployed will be pointing to individual branches for their target version, for instance branches/ui-activities-1.1. This branch will be identical to the trunk except that their version numbers will be the new stable version, moving from 0.2-SNAPSHOT in the trunk to 0.2 on the module-0.2 branch, and a bumped 0.3-SNAPSHOT on the trunk.

This allows Hudson to do a complete build of Taverna in one go without needing to deploy the individual modules. As the Raven plugin system uses the Maven version numbers at runtime, the POMs and their dependencies must all be in stable versions when we're preparing a release. This phase allow us to fix any glitches in the POM, for instance if a particular module depends on an older version of wsdl-generic than expected. Once all version numbers are stable and the branched build tree runs, the Hudson build from that branch will be the first internal release candidate

As the myGrid team perform extensive testing of the internal candidates, some bugs might be discovered which needs to be fixed. In this phase it is the release manager who will pull down individual new commits from the trunk of the affected module, and apply them to the stable branch. When a module is considered tested or not considerably changed since previous version, it will be individually tagged, say as tags/activities-1.2, and the SVN externals of the branched build tree updated. Hudson will provide new internal candidates for testing.

Golden master

Once all modules have been tested, tagged and the build tree is built solely from stable-versioned tagged versions, the build tree itself is tagged with the product version, and a golden master is built from this tag using Hudson. This release candidate can in theory be released as it is, and is used to (currently manually) build the installers for Windows and OS X. The Linux release is done by deleting Windows files from the golden master. The source code release is done by making a copy of the build branch - but with the phantom POM files edited to also build previously released/deployed modules.  (The reasoning being that anyone interested in building from source don't want to download the binaries from the Maven repository). 

If a critical bug is discovered in this phase, we will change Hudson to again build from the branch of the build tree, re-open the module to be changed by changing that particular SVN external to the branch, and do new release candidates until the bug is confirmed fixed. The modified modules would have to be re-tagged, before forming another golden master. If the change is sufficiently small, we might cheat and keep the build tree on the final tag, but on the affected module apply the change on the branch and tag it right away, to immediately build a new golden master. As a developer you can test the fix by copying the modified JAR into the previous golden master - but the new golden master will have to be built from scratch to be sure the release is built from a tagged and final version of the source code.

Distributing download packages

The individual installers are distributed for internal installation/OS testing from an internal web site, before being uploaded to the official download site at, in addition to mirror copies at Google Code. The internal copy of the web site has at this stage already been prepared with the new release notes, etc, and are finalized by updating the download page for the download links, file sizes and checksums.

We typically leave the download files over the night/weekend before making the web site live. (Note: We have a rule to never release on Fridays.)

Changes at this stage are highly unlikely unless we find for instance that Taverna does not start up on Alan's 64-bit Windows Vista at home (and that did work in the previous release - old bugs are not considered at this point).

Critical changes at this stage will typically be scheduled for an online update which we can provide over the following two weeks using a similar approach on a new branched build tree, but deploying/testing using an internal plugin site, before finally deploying to the official Maven repository and making the update available from the official plugin site.

When a full release goes live, we make a copy of the internal testing web site's database, and modify the Wordpress installation of to use the new database. The myGrid site is updated with the release notes. The release notes are also sent out by email to the taverna-users and taverna-hackers mailing lists. A Python script does the mass-mailing to registered users who have been asked to be notified.


See also:

  • None