Skip to end of metadata
Go to start of metadata

Taverna development and release procedures

The procedures we follow when developing code and making Taverna releases.


  • Project Manager - responsible for ensuring procedures are followed, has final say on when or whether a release goes out and what is included within it.
  • Maintainer - responsible for routine maintenance and processing a release. Regularly checks (say weekly) that versions have been updated to SNAPSHOT for new development.
  • Developer - somebody that addresses Tasks and commits to VCS
  • Tester - tests a release. Should include both developers and users.


  • Developers work from tasks in the issue tracker JIRA - be it bugs, new features, etc. If a task is not in JIRA is should be added and linked to the current version under development.
  • Commits of code should be tagged with the
  • When a developer finishes a task, it should be have its status changed to Resolved
  • All development (new and bug-fixing) is "adequately" covered with unit and integration tests. Common sense prevails here.
  • All commit messages should contain the relevant Jira issue number in the beginning, for instance T2-1234.
  • When a developer starts to work on a fresh modules he/she must check the version for that module. If it is not SNAPSHOT, then it must be incremented and have -SNAPSHOT appended.


  • 2 weeks before a release preparation, a notification must be made through the taverna hackers list about the planned code freeze. The actual release date would include additional time for testing, preparation and any last-minute changes, at least a week later.
  • After these 2 weeks, the code freeze is announced.
  • The maintainer checks out the entire source tree from the relevant build project.
  • The source tree is branched according to the release version  (See [Release branching procedure|developer:Release branching procedure])
    * The maintainer, working on the new branch, updates the dependencies by removing the snapshot versions (typically using find and sed)
    * Modules which are not updated for this release, are instead pulled in from their previously tagged/deployed versions.
    * The maintainer makes sure the code builds and runs locally
    * Then the new poms, and other files such as plugin.xml files, are now committed. The maintainer makes a notes of the commit changes (using VCS logs, automated emails etc).

* A Hudson build is made for this particular version, checking out from the branch. This build forms the first internal release candidate which is distributed for testing.  (See [Release branching procedure|developer:Release branching procedure])

* At this point any bug-fixes or last minute tweaks are applied to the trunk, and merged across to the release branch.
* After a release is prepared, and packaged, it is handed to the testers.
* When a release is ready and sent out, the maintainer does a tag on the branch to mark the release. (See Release branching procedure)
* The Hudson build is modified to build from the release tag - this forms a golden master
* The installers are created and uploaded from a golden master built by Hudson (See [Release branching procedure|developer:Release branching procedure])

  • Once the downloads are live, the java artifacts are deployed to the myGrid repository, from the successful, tested golden master build using Hudson's "redeploy" function
  • The official Maven module number page is updated
  • The Maven archetype and plugin documentation is updated
  • The maintainer checks that all changes done on the branch have been merged to the trunk.
  • The maintainer, using diffs and his previous notes on version changes, updates the versions on the trunk. Any development just on the trunk has their versions updated to x.+1-SNAPSHOT.
  • Normal development commences on the trunk, with the branch used for emergency bug-fix updates.


  • Testers work through the JIRA issues for the release marked as Resolved. These are tested to confirm they are solved, and if fixed marked as Closed, otherwise re-opened.
    • The tester must be different from the developer(s) who did the implementation of an issue.
  • Testers follow a standard test script that tests the overall behaviour of the application. We can build this based upon the Taverna 1 test script.

Dependency mananagement

We've found that the original idea of only updating version numbers and releasing changed modules did not work very well with the Raven plugin system. The reason is that Raven is very picky about the stated version numbers of a dependency. So a change of a single module file-manager-impl in ui-impl means that any module that imports file-manager-impl also needs a new version, as their POM has been updated. This cascades, typically ending up with everything getting a new version number, at least for the "higher level" modules.

The procedure now is that a whole module tree (like net.sf.taverna.t2.core or net.sf.taverna.t2.ui-api) is given a new version number if anything inside it has changed, or any of the module trees which it depends on have changed. This is simpler to manage, as these version numbers are given as <properties> in each module tree.

Coding guidelines

  • Write unit tests before coding, to verify bug and desired behaviour
    • Building and unit tests should not depend on external services or network access
  • Add integration tests to a integration test module
    • These are allowed to access the internets
  • Ensure build is not broken before committing
  • Monitor emails from Hudson about build and test failures
    • Fix build issues immediately
  • If unsure about where to place code, contact the _release manager_ to confirm whether your code needs a new module, and where it should go
  • Never copy code. If code could be reused, feel free to do a refactoring to a common class/module. Coordinate with other team members.
  • External dependencies must be to stable versions pulled from an official Maven repository - and should not be added to the project as JARs or copied source code
    • If a special deployment or patch is needed, contact the _release manager_ to add them to the myGrid repository
  • All source code must have the required file header with the University of Manchester copyright (with the copyright year(s) updated)
  • Update the @Author tag on any class modified
  • Write JavaDoc for any methods that are public or which purpose can be tricky to understand. 
    • Getters and setters are not as important as  "setName() - set the name to a name", but must be documented for fields which meaning are not obvious
    • Add a with package level JavaDoc pointing to the most important classes to start with
  • All commit messages should have the relevant Jira issue number
    • If an issue does not exist, create it as a new issue or as a sub-task of the overall issue. 
    • The Jira issues form part of the release notes and are linked in to the Hudson build.


  • None