...
- 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.md 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 and put it in the $NUTCH_HOME/ivy directory
- Set the ${MVN_HOME} environment variable on the machine you are executing the release from. This must point to the Apache Maven home directory.
- Ensure you have an apache-release profile in your local ~/.m2/settings.xml as detailed in the prerequisites above
- Set the ${MAVEN_GPG_PASSPHRASE} environment variable on the machine you are executing the release from. This must be the GPG passphrase associated with the key you are using to sign the release artifacts.
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 repository, close it.
- 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 create a new directory for the release and copy CHANGES.md herethere
- svn co https://dist.apache.org/repos/dist/dev/nutch/ nutch_staging
- mkdir nutch_staging/${release_version}
- cp CHANGES.md 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
...
- Update version numbers to A.B-dev (assuming A.B is next release number) 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"
- Update CHANGES.txt md with header for new changes.
- Ensure that a new version in JIRA exists for development snapshots (A.B-dev). If this is not there then create one.
...