...
- 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"
- if necessaryin 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 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
...
head back over to the staging repos and RELEASE them into the wild.
Move the artifacts from the release management area to the release area as follows:
svn mv https://dist.apache.org/repos/dist/dev/nutch/$release.version https://dist.apache.org/repos/dist/release/nutch/$release.version --message "Release Apache Nutch $release.version"
- Wait 24 hours for release to propagate to mirrors.
- wait until the release is visible on the release page
- update the Nutch website (see nutch-site README how to)
- add
- the new release info to the doap.rdf file (content/doap.rdf), 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
Publish new site as per the documentation within the site readme
- copy the replace the folder content/documentation/javadoc/apidocs/ with the Java API doc folder of the current version
(only if generating the Miredot REST API docs succeeded) into the svn directory cms_site/content/apidocs/apidocs-X.X and commit it copy the Miredot REST API doc folder (remember this can be located in $NUTCH_HOME/target/miredot) into the svn nutch-site directory cms_site/content/miredot/X.Y and commit it
update the links to the new Java API doc in javadoc.html version numbers on the javadoc page (content/documentation/javadoc/index.md) and the wiki FrontPage
- update the links to release packages on the downloads page (content/download.md)
write a short announcement place a note about the new release on the main pagein the news section (content/news/)
- build the Nutch website, verify the changes and deploy the site
- Release the version on Jira
- (if necessary) prepare announcements regarding CVEs resolved with this release of Nutch, see the Apache security howtos
Send announcements to the user and developer lists as well as announce@apache.org
Finally, don't forget to remove the previous release from dist.apache.org to reduce the load on ASF mirrors, see when-to-archive and NUTCH-1742.
...