Release Process


Before creating a release, ensure that:

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/

You can find your keyId using gpg --list-keys.

 The apacheArchivesFolder should be the full path to your dev archives workspace. The build will copy files to this folder; see further notes below.

Release Steps

Generate the Release

  • Update your workspace to the release branch
    • For current work, the release branch is master
    • When creating bug fix releases for older releases, the branch will match the release, e.g., 5.3
  • 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 copy the source, binary, and documentation archives to your dev archives workspace
  • Tag the release in Git, then push the changes up to the Apache repository:
    • git tag 5.x
    • git push --tags
  • Login to Nexus and close the automatically created staging repository

Commit the Archives

  • The build will have copied archive files to your dist workspace
  • svn add the new files
  • svn commit to copy the files up to Apache (this is slow)
    • Use the full version number as the commit message, e.g., 5.4-beta-26
  • You can verify the files via the web:

Bump the Version Number

  • Update build.gradle to increment the version number
  • Increment the minor version number (inside the tapestryVersion method, near the top of the file)
  • Commit and push the changes

Send Vote

  • Send vote email
  • Wait 3 days
  • The vote is successful if there are at least three +1's and more +1 than -1
  • Only PMC members may cast binding votes

Update JIRA and generate release notes 

  • 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

Release the Maven Artifacts

  • Login to Nexus and release the version's repository
    • Enter "Apache Tapestry 5.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

Release the Archives

  • Copy the release archives files (including checksums and GPG signatures) to the release archives workspace
  • Change to the release archives workspace
  • svn add and svn commit, as with the dev archives workspace

Release the Kraken

  • This occurs automatically


  • You must wait at least 24 hours for the archives and artifacts to be distributed to the Apache mirrors and to the central Maven repository

Update Documentation

  • Update the release number listed in the following pages in the Confluence wiki:
  • Change to the site content workspace
  • svn update to get any recent changes
  • Edit archetype-catalog.xml to add or update a new entry for the release
  • Update the release number and date inside doap.rdf  (this is a description file for the project)
  • svn commit


A template for the vote e-mail:

I often embellish this template with extra detail.

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