This page is prepared and maintained for/by Nutch committers. You need committer rights to create a new Nutch release.


  1. Make a branch trunk or 2.x as follows
    • svn copy${path-to-release} -m "Nutch X.Y branch" 

  2. Create a new release in JIRA. If you do not already have these privileges ask your PMC Chair.
  3. Push off all open issues to the next release; any critical or blocker issues should be resolved on mailing list. Discuss any issues that you are unsure of on the mailing list.

Prepping the Release Candidate

  1. From now on, use the branch created above.
  2. Update version numbers (from X.Y-dev to X.Y) for release in:
    • nutch-default.xml - http.agent.version property
    • - version property and year property
  3. Update CHANGES.txt with release date and (if needed) add additional changelog entries. It's also good practice to include a link to the Jira report.
  4. Check if documentation needs an update. Although this may be a huge task at any given time, any minor contribution is better than nothing at all.
  5. Commit all these changes.
  6. Make a clean checkout.
  7. Build it.
    • ant tar

  8. Run unit tests.
    • ant test

  9. Do basic test to see if release looks ok - e.g. install it and run example from tutorial.
  10. Run the docker containers as per the guidance for trunk and 2.x HBase and 2.x Cassandra

  11. Get hold of maven-ant-tasks-2.X.X.jar from|gav|1|g%3A%22org.apache.maven%22%20AND%20a%3A%22maven-ant-tasks%22 and put it in the ivy directory

  12. Execute ant -lib ivy deploy from $NUTCH_HOME, this will sign the Maven artifacts (sources, javadoc, .jar) and send them to a Apache Nexus staging repository. Details of how to set this up can be found here. N.B. Ensure that you have an apache-release profile contained within ~/.m2/settings.xml

  13. Once you've read, and are happy with the staging repos, close it.

  14. Remove the maven-ant-tasks jar from the ivy directory
  15. If you do svn status, you will see that a pom.xml has been created. Delete this. It is not required and just confuses users.
  16. Tag it.
    • svn copy -m "Nutch X.Y release." 

  17. run the ant targets for tar-bin, zip-bin, zip-src and tar-src (if releasing trunk) and only the latter two if releasing 2.X (this is because 2.x is only released as source). The generated artifacts can be found in $NUTCH_HOME/dist.

  18. Sign it all of the generated artifacts - Step-By-Step Guide to Signing Releases N.B. an md5, sha and asc should accompany each release artifact. The result (for trunk) should look like this

mary@mary-ISTART-2380 ~/Downloads/apache/branch-1.8/dist $ ls -al
total 172192
drwxrwxr-x  2 mary mary     4096 Mar  1 14:24 .
drwxrwxr-x 10 mary mary     4096 Mar  1 14:16 ..
-rw-rw-r--  1 mary mary 83696145 Mar  1 14:16 apache-nutch-1.8-bin.tar.gz
-rw-rw-r--  1 mary mary      836 Mar  1 14:20 apache-nutch-1.8-bin.tar.gz.asc
-rw-rw-r--  1 mary mary       78 Mar  1 14:21 apache-nutch-1.8-bin.tar.gz.md5
-rw-rw-r--  1 mary mary      260 Mar  1 14:23 apache-nutch-1.8-bin.tar.gz.sha
-rw-rw-r--  1 mary mary 85086686 Mar  1 14:17
-rw-rw-r--  1 mary mary      836 Mar  1 14:20
-rw-rw-r--  1 mary mary       75 Mar  1 14:21
-rw-rw-r--  1 mary mary      222 Mar  1 14:23
-rw-rw-r--  1 mary mary  2774577 Mar  1 14:18 apache-nutch-1.8-src.tar.gz
-rw-rw-r--  1 mary mary      836 Mar  1 14:20 apache-nutch-1.8-src.tar.gz.asc
-rw-rw-r--  1 mary mary       78 Mar  1 14:22 apache-nutch-1.8-src.tar.gz.md5
-rw-rw-r--  1 mary mary      260 Mar  1 14:23 apache-nutch-1.8-src.tar.gz.sha
-rw-rw-r--  1 mary mary  4696103 Mar  1 14:19
-rw-rw-r--  1 mary mary      836 Mar  1 14:21
-rw-rw-r--  1 mary mary       75 Mar  1 14:22
-rw-rw-r--  1 mary mary      222 Mar  1 14:23
  1. Make sure that all artifacts are editable by fellow committers e.g. chmod 775

  2. Check out the release management area at{release.version} and copy all artifacts to here then commit this.

  3. Make sure your pgp key is listed in the Nutch KEYS file located at

  4. Create and open a VOTE thread on user@ and The VOTE must pass with 3 +1 binding VOTE's before any release can take place. A VOTE thread usually takes the form

Hi user@ & dev@,

This thread is a VOTE for releasing Apache Nutch 1.8 RC#2. The release candidate comprises the following components.

* A staging repository [0] containing various Maven artifacts
* A branch-1.8 of the trunk code [1]
* The tagged source upon which we are VOTE'ing [2]
* Finally, the release artifacts [3] which i would encourage you to verify for signatures and test.

You should use the following KEYS [4] file to verify the signatures of all release artifacts.

Please VOTE as follows

[ ] +1 Push the release, I am happy :)
[ ] +0 I am not bothered either way
[ ] -1 I am not happy with this release candidate (please state why)

Firstly thank you to everyone that contributed to Nutch. Secondly, thank you to everyone that VOTE's. It is appreciated.

(on behalf of Nutch PMC)

p.s. Here's my +1
  1. Once the 72 hour period expires it is time to close the VOTE thread with a RESULT thread. This should simply state the outcome of VOTE'ing (including how many binding VOTE's were received. Finally it should included whether the VOTE passed and if the released can be made.
  2. In the instance where the VOTE does not pass, the release manager should roll bak all of the work above as well as DROP the staging artifacts.

Making the Release

  1. head back over to the staging repos and RELEASE them into the wild.

  2. Move the artifacts from the release management area to the release area as follows svn mv$release.version$release.version --message "Release Apache Nutch $release.version" 

  3. Wait 24 hours for release to propagate to mirrors.
  4. Add the new release info to the doap.rdf file, and double check for any other updates that should be made to the doap file as well if it hasn't been updated in a while. If this is the case please see here

  5. Deploy new Nutch site (according to Website_Update_HOWTO). This should include the new Javadoc for the release. Publish new site as per the documentation within the site readme

    1. copy the Java API doc folder into the svn directory cms_site/content/apidocs/apidoc-X.X and commit it

    2. update the links to the new Java API doc in javadoc.html and the wiki FrontPage

    3. place a note about the new release on the main page

  6. Send announcements to the user and developer lists as well as

  7. Finally, don't forget to remove the previous release from to reduce the load on ASF mirrors, see when-to-archive and NUTCH-1742.

Preparing for new development

  1. If needed create a branch for release maintenance(can be done when first commit to branch would be needed).
    •  svn copy \ \ -m "Nutch X.Y release maintenance branch." 

  2. Update version numbers to A.B-dev (assuming A.B is next release number) in:
    • nutch-default.xml - http.agent.version property
    • - version property and year property
  3. Update CHANGES.txt with header for new changes.
  4. Ensure that a new version in JIRA exists for development snapshots (A.B-dev). If this is not there then create one.

Good Luck :)


Release_HOWTO (last edited 2015-09-23 01:05:17 by LewisJohnMcgibbney)