Page History

...

1. Create a new release in JIRA. If you do not already have these privileges ask your PMC Chair.
2. 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.
3. Create a branch branch-x.x, from now on, use the branch created above.
4. Update version numbers (from X.Y-SNAPSHOT to X.Y) for release in:
   • conf/nutch-default.xml - http.agent.version property
   • default.properties - version property and year property

   • src/bin/nutch - version number in echo "nutch X.Y"

5. Check the (copyright) year in NOTICE.txt, update to current year if necessary
6. Update CHANGES.txt with release date and (if needed) add additional changelog entries (from Jira Report). It's also good practice to include a link to the Jira report.
7. 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.
8. Commit all these changes to the branch you are releasing.

9. To avoid that "forgotten" files in your development environment are packaged, make a clean checkout for the release branch or tag:

   • cd ...
     git clone --branch branch-x.x https://github.com/apache/nutch.git branch-x.x
     cd branch-x.x

10. Run unit tests.

    • ant test

11. Do basic test to see if release looks ok - e.g. install it and run example from tutorial.

12. Run the docker container

13. Get hold of the most recent version of maven-ant-tasks-2.X.X.jar from and put it in the $NUTCH_HOME/ivy directory

14. Ensure you have the ${MVN_HOME} environment variable set correctly on the machine you are executing the release from
15. Ensure you have an apache-release profile in your local ~/.m2/settings.xml as detailed in the prerequisites above

16. 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

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

18. Build the Miredot REST documentation courtesy of our good friends over at Miredot which we can post along with the release:              ant -lib ivy restdocs
    If the build fails, try to resolve the dependencies via Maven (a pom.xml has just been created) and build again:
                . Once built it can be located within $NUTCH_HOME/target/miredot

    1. mvn dependency:resolve

               
    1. mvn dependency:resolve-plugins
               
    1. ant -lib ivy restdocs
    
    If all builds well then the REST documentation can be located within $NUTCH_HOME/target/miredot
19. Remove the maven-ant-tasks jar from the ivy directory
20. If you do git status, you will see that a pom.xml (and it's associated signature) has been created. Delete this. It is not required and just confuses users.
21. Tag the release candidate.

    • git tag -a release-X -m "Apache Nutch X RC#X Tag"

22. Push it to the remote host.

    • git push origin release-X

23. run the ant targets for zip-bin, tar-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.

24. Sign it all of the generated artifacts - Step-By-Step Guide to Signing Releases ' - Consider using Chris Mattmann's Apache Utility Scripts. After the signing each release package must be accompanied by the *.asc and the *.sha512 signature file.

25. Check out the release management area at https://dist.apache.org/repos/dist/dev/nutch/{release.version} and copy all artifacts and the CHANGES.txt to here then commit this.

26. Make sure your pgp key is listed in the Nutch KEYS file located at http://www.apache.org/dist/nutch/KEYS or better yet, use https://id.apache.org/ and add your PGP there, and it will then appear in Apache Nutch's Automatically Generated Keys

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

...