THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- 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 REST documentation courtesy of our good friends over at Miredot which we can post along with the release. 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
...