...
- Create a new release in JIRA. If you do not already have these privileges ask your PMC Chair.
- 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.
- Create a branch branch-x.x, from now on, use the branch created above.
- 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"
- in default.properties update the links to Javadocs of important dependencies (eg. Hadoop)
- 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.
- 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.
- Commit all these changes to the branch you are releasing.
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
- Run unit tests.
ant test
- Do basic test to see if release looks ok - e.g. install it and run example from tutorial.
Run the docker container
Get hold of the most recent version of maven-ant-tasks-2.X.X.jar from and and put it in the $NUTCH_HOME/ivy directory
- Ensure you have the ${MVN_HOME} environment variable set correctly on the machine you are executing the release from
- Ensure you have an apache-release profile in your local ~/.m2/settings.xml as detailed in the prerequisites above
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
Once you've read, and are happy with the staging repos, close it.
Build the Miredot REST documentation. Once built it can be located within $NUTCH_HOME/target/miredot
mvn dependency:resolve
- mvn dependency:resolve-plugins
- ant -lib ivy restdocs
- Remove the following artifacts
- $NUTCH_HOME/ivy/maven-ant-tasks-2.X.X.jar
- $NUTCH_HOME/pom.xml
- $NUTCH_HOME/pom.xml.asc
- $NUTCH_HOME/target
- Tag the release candidate.
git tag -a release-X -m "Apache Nutch X RC#X Tag"
- Push it to the remote host.
git push origin release-X
Run the packaging tasks. The generated artifacts can be found in $NUTCH_HOME/dist. If you experience issues during this stage you may need to prune/delete ~/.ivy2/cache/*
ant zip-bin && ant tar-bin && ant zip-src && ant tar-src
Check out the release management area, copy all artifacts and the CHANGES.txt here
- svn co https://dist.apache.org/repos/dist/dev/nutch/ nutch_staging
- mkdir nutch_staging/${release_version}
- svn co https://dist.apache.org/repos/dist/dev/nutch/ nutch_staging
- 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.
- Copy all of the release artifacts to the staging directory and commit to the SVN server
- cp $NUTCH_HOME/dist/*.tar.gz* $NUTCH_HOME/dist/*.zip* nutch_staging/${release_version}/
- svn add nutch_staging/${release_version}
- svn ci -m "Stage Apache Nutch ${release_version} RC#1"
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
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
...