Release Process


Before creating a release ensure:

  • You have setup your own public OpenGPG key signature for signing the distribution
  • You can login to Nexus

GIT and Deployment Credentials

To successfully create a release, you will need to update your Gradle settings with the credentials for your git user and the deployment user. These credentials are stored in the Gradle configuration file ~/.gradle/

Release Steps

The process can be summarized as:

  • Update your workspace to the release branch, currently 5.3: git co 5.3
    • It is normal for the release branch to be created a week or more before the planned release
  • Update build.gradle to set the version number, then git commit
    • Don't forget to set it back to 5.x-SNAPSHOT after the release
  • Run the build using gradle generateRelease
    • This will create, sign, and upload JAR files and other artifacts to the Nexus repository
    • It will also create, sign, and upload the source and javadoc archives to your ~/public_html/tapestry-releases folder of your Apache home directory (at
  • Tag the release in Git, then push the changes up to the Apache repository:
    • git tag 5.x.x
    • git push --tags
  • Update build.gradle to bump the version number to 5.x(.y)?-SNAPSHOT, then git commit
  • Login to Nexus and close the automatically created staging repository, and note its url
  • Use the Manage Versions page in JIRA to add a new version (this is often not necessary as it is often created by someone earlier)
  • Release the version, moving outstanding issues to the next version
  • Generate HTML Release Notes
    • Visit the TAP5 Versions pages in JIRA
    • Choose the correct version number
    • Click "Release Notes" (upper right corner of the page)
    • Create a new Confluence child page of Release Notes (it may already exist)
    • Update with text about any unusual aspects of the upgrade (especially, non-backwards compatible changes)
    • Paste the HTML release notes content into the new page (you'll have to use the {html} macro)
    • Rename the "Bug" heading to "Bugs Fixed", "Improvement" to "Improvements Made", "New Feature" to "New Features Added"
    • Update Release Notes index page to point to the new page
  • Send vote email ... 3 days pass
  • Login to Nexus and release the version's repository
    • Enter "Apache Tapestry 5.x.x" (adjust as necessary) for the message
    • The version will disappear from the list of repositories after releasing it
    • Releasing will ultimately get the artifacts up to the central Maven repository
  • Documentation and Downloads:
    • SSH to and move the source and javadoc archives to /www/
    • Create (if necessary) /www/ to store documentation for the release
    • Unpack the JavaDoc archive into the directory (it will become the apidocs directory)
    • Update SVN PubSub repo at to clean old api dir and relink all symlinks to point to the new 5.x.x directory
  • Once files reach all mirrors, update the Downloads Page
  • Create a Confluence blog entry to describe the new release (this will automatically appear on the Tapestry home page)
  • Edit /www/ to add or update a new entry for the release
  • Update the release number listed in the following pages in the Confluence wiki:
  • Update the release number and date at

A template for the vote e-mail:

I've created and uploaded a release of Tapestry 5.x.x, ready to be voted upon.

The source and source downloads are uploaded to:

and the Maven artifacts staged to:
Please examine these files to determine if the new release, 5.x.x, is ready.

I've also created a 5.x.x tag in Git:;a=commit;h=c5600a8de7645fb7bd5cc21b38f8902a36c1b840

Vote will run for three days; On a successful vote, I'll release the Maven
artifacts, and move the source and javadoc distributions from these directories
to the proper distribution directories and update the Tapestry site
documentation, and send out appropriate notifications.

I often embellish this template with extra detail.

Lately, I append a text version of the JIRA release notes as well.