How does cTAKES manage releases?

We follow the standard ASF release process. One of the committers would volunteer to take on the release manager role for a given release. A few days will be spent stabilizing the cTAKES development trunk, improving its documentation and test coverage. The maven release plug-in (mvn release:prepare/perform) is recommended for this purpose (See details below).

Open JIRA issues will be reviewed and rearranged accordingly. Many of the issues will get resolved during this process and the remaining few will be accordingly prioritized and scheduled for a future release. The unit tests and integration tests will be used extensively during this critical period to keep the development in its most stable form. Move any existing open issues to the next release.

  1. Send an email out to ctakes-dev@ with the intention of creating a release and that you will be volunteering for the release manager role.
  2. Decide if you like to A) freeze any development in trunk until the release has been completed. B) Create a branch that this release will be created from and development in trunk could continue.
  3. If B) create a branch from trunk (such svn copy from trunk to branches/3.1.1). Edit the SVN connections info in the root pom.xml to the branch instead of trunk. Continue with the steps below as usual, but just work off the newly created branch instead of trunk. Note: It is the RM role to ensure that any fixes done in the branch are also done back in trunk.

Finally the release manager would trigger the release build, sign the generated artifacts and host them on Apache Nexus & Maven Central. A release vote will be called urging all those interested to review the packages and provide feedback. Upon receiving the necessary number of votes, the artifacts will be uploaded to the appropriate servers for distribution.

Preparing your Environment

  1. Read:
  2. Setup your PGP keys:

Preparing a Release using Maven

Note: Using 3.1.1 as an example

Maven may prompt you to enter your PGP passphrase and SVN password multiple times for each module. Just enter them in - as passing them in through the CLI is found to be insecure.

  1. $svn co ctakes
  2. $mvn release:clean
  3. $mvn release:prepare -DdryRun={false} -Dresume={false} -DautoVersionSubmodules=true

Release: 3.1.1

Tag: ctakes-3.1.1

Next Dev Release: 3.1.2-SNAPSHOT

Changes for the release

Update ctakes-distribution/RELEASE_NOTES.html and check in change into trunk or the branch for the release if using a branch

Performing the build from the tag

If you do a release:perform, it does a clean checkout from the tag (to ensure it's clean). rebuild and then deploy.

This will place the artifacts to the ASF Nexus area for staging for voting.

  1. $mvn release:perform
    For example:
    mvn release:perform -DconnectionUrl=scm:svn:
  2. [If need to revert] $ mvn release:rollback (Works if you didn't do a release:clean yet)
  3. log into apache's nexus area
  4. close the staging respository

Publishing Artifacts to Dev

The step above with mvn release:perform will publish the artifacts to

Commit the artifacts to

Preparing the RC for a VOTE

Send an email like the following to with the subject line: [VOTE] Release Apache cTAKES


This is a call for a vote on releasing the following candidate as Apache cTAKES 3.1.1.

For more detailed information on the changes/release notes, please visit:

The release was made using the cTAKES release process documented here:

The candidate is available at: /.zip

The tag to be voted on:

The MD5 checksum of the tarball can be found at: /.zip.md5

The signature of the tarball can be found at: /.zip.asc

Apache cTAKES' KEYS file, containing the PGP keys used to sign the release:

Please vote on releasing these packages as Apache cTAKES 3.1.1. The vote is open for at least the next 72 hours.
Only votes from the cTAKES PMC are binding, but folks are welcome to check the release candidate and voice their approval or disapproval. The vote passes if at least three binding +1 votes are cast.

[ ] +1 Release the packages as Apache cTAKES 3.1.1 
[ ] -1 Do not release the packages because...

Also note that the convenience binary is: /.zip

(name here)

P.S. Here is my +1.

If VOTE passes with 3+ cTAKES PMC votes and majority approval, move onto next step. (See Relase Votes) If VOTE does not pass, repeat steps 3-on until it does.

Publishing Artifacts to dist after VOTE Passes

Move the artifacts from Dev to Dist For example:

 svn copy \  \     \
   -m "Publish artifacts to release directory"
The svnpubsub will automatically push those to the dist area on all of the mirrors: You can verify by visiting:

Release from Staging Repository after VOTE Passes

Log into Apache Nexus and Release the staging repository. Remember to drop any previous candidate staging repositories whose VOTE did not pass.

Creating Final Tag from RC Tag after VOTE Passes

For example, if the VOTE for rcX passes for release A.B.C

 svn copy \  \      \
   -m "Copying tag of accepted RC for the release to final actual release tag"

Update documentation

Wait for versions to hit the mirrors (hint: keep checking until you see something). Once the release hits:

Sending Announcement Email

Wait for versions to hit the mirrors (hint: keep checking until you see something).

Once release hits send announcement email to announce@a.o and dev@ctakes and user@ctakes. This needs to be done from your email address or the email will bounce from the announce list. Gmail forwarding can help here and is a snap to set up. It's even easier then the instructions there as it will recognize your email address and default to Apache settings.


After announce, if the release included a new component, it's a good idea to check the list of cTAKES components within JIRA to verify new component(s) were added there, so users can report issues to the appropriate component.

Copyright © 2011-2013 The Apache Software Foundation, Licensed under the Apache License, Version 2.0. Privacy Policy
Apache and the Apache feather logo are trademarks of The Apache Software Foundation.