...
- 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"
- Check the (copyright) year in NOTICE.txt and default.properties, update to current year if necessary
- 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 containers as per the guidance for trunk and 2.x HBase and 2.x Cassandra
Get hold of maven-ant-tasks-2.X.X.jar from http://search.maven.org/#search|gav|1|g%3A%22org.apache.maven%22%20AND%20a%3A%22maven-ant-tasks%22 and put it in the ivy directory
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.
Run ant -lib ivy restdocs this builds us some kick ass Build the 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:
mvn dependency:resolve
mvn dependency:resolve-plugins
ant -lib ivy restdocs
If all builds well then the REST documentation can be located within $NUTCH_HOME/target/miredot- Remove the maven-ant-tasks jar from the ivy directory
- 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.
- 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 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.
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.
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.
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
...