Differences between revisions 1 and 56 (spanning 55 versions)
Revision 1 as of 2005-08-11 19:09:39
Size: 1526
Editor: 217
Comment:
Revision 56 as of 2017-11-13 08:26:57
Size: 8154
Comment: Should build the release packages from a clean checkout
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
''This page is prepared for Nutch committers. You need committer rights to create a new Nutch release.'' = Introduction =
''This page is prepared and maintained for/by Nutch committers. You need committer rights to create a new Nutch release.''
Line 3: Line 4:
= Making a release. = <<TableOfContents(3)>>
Line 5: Line 6:
 1. Update version numbers (from X.Y-dev to X.Y) for release in :
  * nutch-default.xml - user agent string
  * default.properties

 1. Update CHANGES.txt with release date and if needed add additional changelog entries.
 1. Check if docs need update.
 1. Update news.
 1. Commit all these changes.
 1. Make a clean checkout.
             {{{svn ...}}}
 1. Build it.
   {{{ant tar}}}
= Prepping the Release Candidate =
        1. Create a new release in JIRA. If you do not already have these privileges ask your PMC Chair.
        1. 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.
        1. Create a branch branch-x.x, from now on, use the branch created above.
 1. 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"}}}
 1. Check the copyright year in NOTICE.txt, update to current year if necessary
 1. 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.
 1. 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.
 1. Commit all these changes to the branch you are releasing.
 1. To avoid that "forgotten" files in your development environment are packaged, make a '''clean''' checkout for the release branch or tag:
                 {{{cd ...}}}
                 {{{git clone https://github.com/apache/nutch.git branch-x.x}}}
                 {{{cd branch-x.x}}}
Line 20: Line 25:
 1. Tag it.
  {{{svn ...}}}
 1. Deploy to releases.
  {{cp to ...}}}
 1. Wait for release to propagate to mirrors??
 1. Deploy new site (according to ["Website Update HOWTO"]).
 1. Update Javadoc on website.
  {{cp to ...}}}
 1. Create version in JIRA for release.
        1. Run the docker containers as per the guidance for [[https://github.com/apache/nutch/tree/trunk/docker|trunk]] and [[https://github.com/apache/nutch/tree/2.x/docker/hbase|2.x HBase]] and [[https://github.com/apache/nutch/tree/2.x/docker/cassandra|2.x Cassandra]]
        1. 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
        1. 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 [[http://www.apache.org/dev/publishing-maven-artifacts.html|here]]. '''N.B.''' Ensure that you have an '''apache-release''' profile contained within ~/.m2/settings.xml
        1. Once you've read, and are happy with the [[https://repository.apache.org/|staging repos]], close it.
        1. Run {{{ant -lib ivy restdocs}}} this builds us some kick ass REST documentation courtesy of our good friends over at [[http://www.miredot.com/|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'''
        1. Remove the maven-ant-tasks jar from the ivy directory
        1. 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.
 1. Tag the release candidate.
  {{{git tag -a release-X -m "Apache Nutch X RC#X Tag"}}}
        1. Push it to the remote host.
                {{{git push origin release-X}}}
 1. 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.
        1. Sign it all of the generated artifacts - [[http://www.apache.org/dev/release-signing.html|Step-By-Step Guide to Signing Releases]] ' - Consider using [[http://github.com/chrismattmann/apachestuff|Chris Mattmann's Apache Utility Scripts]].
        1. Check out the release management area at https://dist.apache.org/repos/dist/dev/nutch/{release.version} and copy all artifacts to here then commit this.
        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 [[https://people.apache.org/keys/group/nutch.asc|Apache Nutch's Automatically Generated Keys]]
        1. 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
{{{
Hi Folks,

A first candidate for the Nutch X.Y release is available at:

  https://dist.apache.org/repos/dist/dev/nutch/X.Y/

The release candidate is a zip and tar.gz archive of the sources in:
(select tag from options below)
https://git-wip-us.apache.org/repos/asf?p=nutch.git;a=tags

The SHA1 checksum of the archive is
<<<fill in>>>

In addition, a staged maven repository is available here:

<<<fill in>>>

Please vote on releasing this package as Apache Nutch X.Y.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Nutch PMC votes are cast.

[ ] +1 Release this package as Apache Nutch X.Y.
[ ] -1 Do not release this package because…

Cheers,
<<<fill in>>>

P.S. Of course here is my +1.
}}}
        1. Once the 72 hour period expires it is time to close the VOTE thread with a RESULT thread. This should simply state the outcome of VOTE'ing (including how many binding VOTE's were received. Finally it should included whether the VOTE passed and if the released can be made.
        1. In the instance where the VOTE does not pass, the release manager should roll bak all of the work above as well as '''DROP''' the staging artifacts.

= Making the Release =
        1. head back over to the [[https://repository.apache.org/|staging repos]] and '''RELEASE''' them into the wild.
        1. 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" }}}
 1. Wait 24 hours for release to propagate to mirrors.
        1. Add the new release info to the [[https://svn.apache.org/repos/asf/nutch/cms_site/trunk/content/doap.rdf|doap.rdf]] file, 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 [[http://projects.apache.org/doap.html|here]]
 1. Publish new site as per the documentation within the [[https://svn.apache.org/repos/asf/nutch/cms_site/README.txt|site readme]]
  1. copy the Java API doc folder into the svn directory {{{cms_site/content/apidocs/apidoc-X.X}}} and commit it
                1. copy the Miredot REST API doc folder (remember this can be located in $NUTCH_HOME/target/miredot) into the svn directory {{{cms_site/content/miredot/X.Y}}} and commit it
  1. update the links to the new Java API doc in [[http://nutch.apache.org/javadoc.html|javadoc.html]] and the wiki FrontPage
  1. place a note about the new release on the [[http://nutch.apache.org/|main page]]
 1. Send announcements to the user and developer lists as well as announce@apache.org
 1. Finally, don't forget to remove the previous release from {{{dist.apache.org}}} to reduce the load on ASF mirrors, see [[http://www.apache.org/dev/release.html#when-to-archive|when-to-archive]] and [[https://issues.apache.org/jira/browse/NUTCH-1742|NUTCH-1742]].
Line 32: Line 89:
 1. If needed create a branch for release maintenance(can be done when first commit to branch would be needed).
       {{{svn ...}}}
 1. Update version numbers for to A.B-dev in:
  * nutch-default.xml - user agent string
  * default.properties
 1. 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"}}}
Line 38: Line 94:
 1. Create version in JIRA for development snapshots.  1. Ensure that a new version in JIRA exists for development snapshots (A.B-dev). If this is not there then create one.
Line 40: Line 96:
We can think about using Apache mirrors for future releases http://www.apache.org/dev/mirror-step-by-step.html?Step-By-Step Step-By-Step Guide to Mirroring Releases] and sign a release. Good Luck :)

<<<FrontPage

Introduction

This page is prepared and maintained for/by Nutch committers. You need committer rights to create a new Nutch release.

Prepping the Release Candidate

  1. Create a new release in JIRA. If you do not already have these privileges ask your PMC Chair.
  2. 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.
  3. Create a branch branch-x.x, from now on, use the branch created above.
  4. 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"

  5. Check the copyright year in NOTICE.txt, update to current year if necessary
  6. 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.
  7. 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.
  8. Commit all these changes to the branch you are releasing.
  9. To avoid that "forgotten" files in your development environment are packaged, make a clean checkout for the release branch or tag:

    • cd ... git clone https://github.com/apache/nutch.git branch-x.x cd branch-x.x

  10. Run unit tests.
    • ant test

  11. Do basic test to see if release looks ok - e.g. install it and run example from tutorial.
  12. Run the docker containers as per the guidance for trunk and 2.x HBase and 2.x Cassandra

  13. 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

  14. 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

  15. Once you've read, and are happy with the staging repos, close it.

  16. 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

  17. Remove the maven-ant-tasks jar from the ivy directory
  18. 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.
  19. Tag the release candidate.
    • git tag -a release-X -m "Apache Nutch X RC#X Tag"

  20. Push it to the remote host.
    • git push origin release-X

  21. 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.

  22. Sign it all of the generated artifacts - Step-By-Step Guide to Signing Releases ' - Consider using Chris Mattmann's Apache Utility Scripts.

  23. Check out the release management area at https://dist.apache.org/repos/dist/dev/nutch/{release.version} and copy all artifacts to here then commit this.

  24. 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

  25. 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

Hi Folks,

A first candidate for the Nutch X.Y release is available at:

  https://dist.apache.org/repos/dist/dev/nutch/X.Y/

The release candidate is a zip and tar.gz archive of the sources in:
(select tag from options below)
https://git-wip-us.apache.org/repos/asf?p=nutch.git;a=tags

The SHA1 checksum of the archive is
<<<fill in>>>

In addition, a staged maven repository is available here:

<<<fill in>>>

Please vote on releasing this package as Apache Nutch X.Y.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Nutch PMC votes are cast.

[ ] +1 Release this package as Apache Nutch X.Y.
[ ] -1 Do not release this package because…

Cheers,
<<<fill in>>>

P.S. Of course here is my +1.
  1. Once the 72 hour period expires it is time to close the VOTE thread with a RESULT thread. This should simply state the outcome of VOTE'ing (including how many binding VOTE's were received. Finally it should included whether the VOTE passed and if the released can be made.
  2. In the instance where the VOTE does not pass, the release manager should roll bak all of the work above as well as DROP the staging artifacts.

Making the Release

  1. head back over to the staging repos and RELEASE them into the wild.

  2. 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" 

  3. Wait 24 hours for release to propagate to mirrors.
  4. Add the new release info to the doap.rdf file, 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

  5. Publish new site as per the documentation within the site readme

    1. copy the Java API doc folder into the svn directory cms_site/content/apidocs/apidoc-X.X and commit it

    2. copy the Miredot REST API doc folder (remember this can be located in $NUTCH_HOME/target/miredot) into the svn directory cms_site/content/miredot/X.Y and commit it

    3. update the links to the new Java API doc in javadoc.html and the wiki FrontPage

    4. place a note about the new release on the main page

  6. Send announcements to the user and developer lists as well as announce@apache.org

  7. 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.

Preparing for new development

  1. 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"

  2. Update CHANGES.txt with header for new changes.
  3. Ensure that a new version in JIRA exists for development snapshots (A.B-dev). If this is not there then create one.

Good Luck :)

<<<FrontPage

Release_HOWTO (last edited 2017-12-22 18:04:42 by SebastianNagel)