Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. git clone release OR git clone -b branch_1x
  2. Add to the <scm> section in tika-parent's pom

    No Format

    Background: for some reason in the 2.x branch these lines are deleted during each release process.  They are not deleted in the 1.x branch.

  3. Update CHANGES.txt with release date (Release X.Y.Z - MM/dd/yyyy (date format matters!) and (if needed) add additional changelog entries.
  4. On the Tika JIRA, create versions X.Y.Z, X.(Y+1), and X.(Y+2), if not already done.
    1. Move any lingering unresolved issues from X.Y.Z to X.(Y+1).
      1. Query open issues: e.g. "project = Tika AND resolution = unresolved AND fixVersion = 1.16"
      2. Upper right, select bulk change
      3. Select all, modify to fixVersion = X.(Y+1)
      4. At the bottom of the screen, unselect the email updates
  5. git add CHANGES.txt && git commit -m "Update CHANGES.txt for X.Y.Z release." && git push origin
  6. Run mvn apache-rat:check and fix any missing license headers / add excluded for properly non-licensed fails
  7. setenv MAVEN_OPTS "-Xms128m -Xmx256m" (or export MAVEN_OPTS="-Xms128m -Xmx256m" if you are using bash)
  8. mvn release:prepare
    1. Make sure all the release numbers are set to X.Y.Z (from X.Y.Z-SNAPSHOT)
    2. When prompted, the scm tag name should be X.Y.Z (version number). If this is a release candidate, the tag should be X.Y.Z-rcN.
    3. Watch for a BUILD SUCCESSFUL message
    4. Make sure you have gnupg (or variant) installed (see
  9. mvn release:perform
    1. Make sure you can log on to
    2. Make sure you have the following entry in your ~/.m2/settings.xml file: The server ID should be apache.releases.https.
  10. Head over to (Apache's Nexus Server)
    1. Login with your ASF username and password
    2. Make sure there is only one repo from your build and that it contains everything. A transmission failure can lead to multiple repositories, none of which are valid... even when mvn release:perform alleges SUCCESS
    3. "Close" the staging repository with message Apache Tika X.Y.Z release candidate #N.
    4. Copy the URL from the closed staged repository for Tika (you'll need this later)
  11. Update CHANGES.txt with a "Release X.Y.Z + 1 - Current Development" section.
  12. Check the contents of target/checkout/target/X.Y.Z/* into ({.asc|.sha512}, tika-app-X.Y.Z.jar{.asc|.sha512} and tika-server-X.Y.Z.jar{.asc|.sha512}, and CHANGES.txt.
    1. svn co
    2. cd
    3. mkdir X.Y.Z
    4. rm -r X.Y.Z-1 (remove the former dist dev version folder)
    5. cp ../release/target/checkout/target/X.Y.Z/* X.Y.Z (copy the artifacts into the new directory)
    6. cd X.Y.Z
    7. mv CHANGES.txt CHANGES-X.Y.Z.txt
    8. make sure the KEYS files is at -- if it isn't there already copy the KEYS file to go along with the jars and other release artifacts; add your key to KEYS if you haven't already
    9. svn add X.Y.Z
    10. svn commit -m "Add Tika X.Y.Z RC#N artifacts."
  13. See the file in target/checkout/target/vote.txt - it contains the contents of the release email you should send (with subject [VOTE] Apache Tika X.Y.Z Release Candidate N to and to Ensure all URLs are correct and update the email to include links to the artifacts from #8 (including .sha512, .asc and CHANGES.txt)
  14. If the VOTE passes:
    1. Send [RESULT] [VOTE] tallying the VOTE to and

    2. Head over to Nexus from #6 and "Release" the repository with message Apache Tika X.Y.Z release (and make sure the box is checked to auto drop).
    3. svn rm* (delete the previous release)
    4. svn mv**
    5. git clone X.Y.Z-rcN
    6. Add final tag for the release and delete the X.Y.Z-rcN tag:
      1. Look up commit for X.Y.Z-rcN commit: git rev-list \-n 1 1.25-rc2; let's say '0090ebac8e4ff4083a9c0c5d3dc55f545ad6f951'
      2. git tag -a X.Y.Z 0090eba -m "Tagging X.Y.Z release"
      3. git tag -d X.Y.Z-rcN
      4. git push --tags
      5. git push origin :refs/tags/X.Y.Z-rcN
  15. If VOTE fails:
    1. Drop the new Tika staging repository on
    2. Make an entry in CHANGES.txt which documents the subsequent changes between release candidates. This is extremely useful if the candidates are cut from master and master has moved on since the release candidate was originally cut.
    3. Go back to #1.
  16. Update the version of any unreleased modules (like tika-dotnet).
  17. Update Tika site.
    1. Update parent version number in the site pom.xml file.
    2. Update the Documentation section of src/site/site.xml. Make sure to add the collapse tag for the now old version.
    3. Update the "Full List of Supported Formats" section of the formats page of version X.Y.Z using TIKA-411; e.g. java -jar release-X.Y.Z/tika-app/target/tika-app-1.15.jar --list-parser-details-apt >> src/site/apt/1.15/formats.apt
    4. Update the version towards the top of X.Y.Z/formats.apt: src/site/apt/1.15/formats.apt
    5. Update the version number in the dependency examples and the commandline options in the new X.Y.Z src/site/apt/X.Y.Z/gettingstarted.apt page.
    6. Update src/site/resources/doap.rdf with the new release.
    7. Create a new example and formats page (truncated to where step 15.3 should go next time) for the next version (but don't list it in the sidebar).
    8. Update src/site/apt/index.apt.vm to include the announcement and change link to previous release CHANGES.txt file (from to
    9. Update src/site/apt/X.Y.Z/index.apt.
      1. Generate the contributor list with
      2. Update the link to the JIRA query (e.g. via Apache's shortening service
      3. Generate the issues list by running CHANGES-X.Y.Z.txt output.txt X.Y.Z
    10. Generate the Javadoc.
      1. unzip
      2. mvn javadoc:aggregate
      3. mkdir .../tika-site/publish/X.Y.Z
      4. mv target/site/apidocs .../tika-site/publish/X.Y.Z/api
    11. Update tika-server documentation:
      1. In the unzipped src release, cd tika-server
      2. mvn -Pserver install (in the tika-server module to build the miredot documentation)
      3. mkdir .../tika-site/src/site/resources/X.Y.Z
      4. rm -r tika-site/src/site/resources/X.Y.Z/miredot (if it exists?!)
      5. cp -r tika-server/target/miredot .../tika/site/src/site/resources/X.Y.Z
    12. Update the downloads section.
    13. Check everything looks good with mvn site:run.
    14. mvn clean install
    15. svn add <any files changed for site> (probably: src/site/apt/X.Y.Z and src/site/resources/X.Y.Z/miredot) && svn commit -m "Update website for X.Y.Z release."
    16. On the Tika JIRA, "release" version X.Y.Z and update any (new) straggler X.Y.Z issues to X.(Y+1).
  18. Send announcements to,, and lists (from your Apache email) - see for a sample. If editing and resending an earlier email, make sure that you use text format and/or make sure that editing the links updates the underlying links and not just the anchor text.
  19. Log on to and add the release data (version and date) to the database