Dear Wiki user, You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.
The "HowToRelease" page has been changed by VinodKumarVavilapalli: https://wiki.apache.org/hadoop/HowToRelease?action=diff&rev1=72&rev2=73 Comment: Minor edit ## page was copied from HowToReleasePostMavenization ''This page is prepared for Hadoop Core committers. You need committer rights to create a new Hadoop Core release.'' - These instructions have been updated for Hadoop 2.5.1 and later releases to reflect the changes to version-control (git), build-scripts and mavenization. + These instructions have been updated for Hadoop 2.5.1 and later releases to reflect the changes to version-control (git), build-scripts and mavenization. Earlier versions of this document are at HowToReleaseWithSvnAndAnt and HowToReleasePostMavenization <<TableOfContents(4)>> = Preparation = - - 1. Bulk update Jira to unassign from this release all issues that are open non-blockers and send follow-up notification to the developer list that this was done. + 1. Bulk update Jira to unassign from this release all issues that are open non-blockers and send follow-up notification to the developer list that this was done. - 1. If you have not already done so, [[http://www.apache.org/dev/release-signing.html#keys-policy|append your code signing key]] to the [[https://dist.apache.org/repos/dist/release/hadoop/common/KEYS|KEYS]] file. Once you commit your changes, they will automatically be propagated to the website. Also [[http://www.apache.org/dev/release-signing.html#keys-policy|upload your key to a public key server]] if you haven't. End users use the KEYS file (along with the [[http://www.apache.org/dev/release-signing.html#web-of-trust|web of trust]]) to validate that releases were done by an Apache committer. For more details on signing releases, see [[http://www.apache.org/dev/release-signing.html|Signing Releases]] and [[http://www.apache.org/dev/mirror-step-by-step.html?Step-By-Step|Step-By-Step Guide to Mirroring Releases]]. + 1. If you have not already done so, [[http://www.apache.org/dev/release-signing.html#keys-policy|append your code signing key]] to the [[https://dist.apache.org/repos/dist/release/hadoop/common/KEYS|KEYS]] file. Once you commit your changes, they will automatically be propagated to the website. Also [[http://www.apache.org/dev/release-signing.html#keys-policy|upload your key to a public key server]] if you haven't. End users use the KEYS file (along with the [[http://www.apache.org/dev/release-signing.html#web-of-trust|web of trust]]) to validate that releases were done by an Apache committer. For more details on signing releases, see [[http://www.apache.org/dev/release-signing.html|Signing Releases]] and [[http://www.apache.org/dev/mirror-step-by-step.html?Step-By-Step|Step-By-Step Guide to Mirroring Releases]]. - 1. To deploy artifacts to the Apache Maven repository create {{{~/.m2/settings.xml}}}:{{{ + 1. To deploy artifacts to the Apache Maven repository create {{{~/.m2/settings.xml}}}: + {{{ <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 @@ -30, +30 @@ }}} = Branching = + When releasing Hadoop X.Y.Z, the following branching changes are required. Note that a release can match more than one of the following if-conditions. For a major release, one needs to make the changes for minor and point releases as well. Similarly, a new minor release is also a new point release. - When releasing Hadoop X.Y.Z, the following branching changes are required. Note that a release can match more than one of the following if-conditions. For a major release, one needs to make the changes for minor and point releases as well. Similarly, a new minor release is also a new point release. + 1. Add the release X.Y.Z to CHANGES.txt files if it doesn't already exist (leave the date as unreleased for now). Commit these changes to trunk and any of branch-X, branch-X.Y if they exist. + {{{ + git commit -a -m "Adding release X.Y.Z to CHANGES.txt" + }}} + 1. If this is a new major release (i.e., Y = 0 and Z = 0) + 1. Create a new branch (branch-X) for all releases in this major release. + 1. Update the version on trunk to (X+1).0.0-SNAPSHOT + {{{ + mvn versions:set -DnewVersion=(X+1).0.0-SNAPSHOT + }}} + 1. Commit the version change to trunk. + {{{ + git commit -a -m "Preparing for (X+1).0.0 development" + }}} + 1. If this is a new minor release (i.e., Z = 0) + 1. Create a new branch (branch-X.Y) for all releases in this minor release. + 1. Update the version on branch-X to X.(Y+1).0-SNAPSHOT + {{{ + mvn versions:set -DnewVersion=X.(Y+1).0-SNAPSHOT + }}} + 1. Commit the version change to branch-X. + {{{ + git commit -a -m "Preparing for X.(Y+1).0 development" + }}} + 1. If this is a new point release (i.e., always) + 1. Create a new branch (branch-X.Y.Z) for this release. + 1. Update the version on branch-X.Y to X.Y.(Z+1)-SNAPSHOT + {{{ + mvn versions:set -DnewVersion=X.Y.(Z+1)-SNAPSHOT + }}} + 1. Commit the version change to branch-X.Y. + {{{ + git commit -a -m "Preparing for X.Y.(Z+1) development" + }}} + 1. Release branch (branch-X.Y.Z) updates: + 1. Update {{{hadoop-project//src/site/markdown/index.md.vm}}} to reflect the right versions, new features and big improvements. + 1. Update the version on branch-X.Y.Z TO X.Y.Z + {{{ + mvn versions:set -DnewVersion=X.Y.Z + }}} + 1. Generate {{{releasenotes.html}}} with release notes for this release. You generate these with: + {{{ + python ./dev-support/relnotes.py -v $(vers) + }}} + If your release includes more then one version you may add additional -v options for each version. By default the previousVersion mentioned in the notes will be X.Y.Z-1, if this is not correct you can override this by setting the --previousVer option. + 1. Update {{{releasenotes.html}}} + {{{ + mv releasenotes.$(vers).html ./hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html + }}} + Note that the script generates a set of notes for HDFS, HADOOP, MAPREDUCE, and YARN too, but only common is linked from the html documentation so the indavidual ones are ignored for now. + 1. Commit these changes to branch-X.Y.Z + {{{ + git commit -a -m "Preparing for release X.Y.Z" + }}} + Now, for any branches in {trunk, branch-X, branch-X.Y, branch-X.Y.Z} that have changed, push them to the remote repo taking care of any conflicts. - 1. Add the release X.Y.Z to CHANGES.txt files if it doesn't already exist (leave the date as unreleased for now). Commit these changes to trunk and any of branch-X, branch-X.Y if they exist. {{{ - git commit -a -m "Adding release X.Y.Z to CHANGES.txt"}}} - 1. If this is a new major release (i.e., Y = 0 and Z = 0) - 1. Create a new branch (branch-X) for all releases in this major release. - 1. Update the version on trunk to (X+1).0.0-SNAPSHOT {{{ - mvn versions:set -DnewVersion=(X+1).0.0-SNAPSHOT}}} - 1. Commit the version change to trunk. {{{ - git commit -a -m "Preparing for (X+1).0.0 development"}}} - 1. If this is a new minor release (i.e., Z = 0) - 1. Create a new branch (branch-X.Y) for all releases in this minor release. - 1. Update the version on branch-X to X.(Y+1).0-SNAPSHOT {{{ - mvn versions:set -DnewVersion=X.(Y+1).0-SNAPSHOT}}} - 1. Commit the version change to branch-X. {{{ - git commit -a -m "Preparing for X.(Y+1).0 development"}}} - 1. If this is a new point release (i.e., always) - 1. Create a new branch (branch-X.Y.Z) for this release. - 1. Update the version on branch-X.Y to X.Y.(Z+1)-SNAPSHOT {{{ - mvn versions:set -DnewVersion=X.Y.(Z+1)-SNAPSHOT}}} - 1. Commit the version change to branch-X.Y. {{{ - git commit -a -m "Preparing for X.Y.(Z+1) development"}}} - 1. Release branch (branch-X.Y.Z) updates: - 1. Update {{{hadoop-project//src/site/markdown/index.md.vm}}} to reflect the right versions, new features and big improvements. - 1. Update the version on branch-X.Y.Z TO X.Y.Z {{{ - mvn versions:set -DnewVersion=X.Y.Z}}} - 1. Generate {{{releasenotes.html}}} with release notes for this release. You generate these with: {{{ - python ./dev-support/relnotes.py -v $(vers) - }}} If your release includes more then one version you may add additional -v options for each version. By default the previousVersion mentioned in the notes will be X.Y.Z-1, if this is not correct you can override this by setting the --previousVer option. - 1. Update {{{releasenotes.html}}} {{{ - mv releasenotes.$(vers).html ./hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html - }}} Note that the script generates a set of notes for HDFS, HADOOP, MAPREDUCE, and YARN too, but only common is linked from the html documentation so the indavidual ones are ignored for now. - 1. Commit these changes to branch-X.Y.Z {{{ - git commit -a -m "Preparing for release X.Y.Z"}}} - Now, for any branches in {trunk, branch-X, branch-X.Y, branch-X.Y.Z} that have changed, push them to the remote repo taking care of any conflicts. {{{ + {{{ git push <remote> <branch> }}} - = Creating the release candidate (X.Y.Z-RC<N>) = These steps need to be performed to create the ''N''th RC for X.Y.Z, where ''N'' starts from 0. + - 1. Run mvn rat-check and fix any errors {{{ + 1. Run mvn rat-check and fix any errors + {{{ mvn apache-rat:check }}} - 1. Set environment variable version for later steps. {{{export version=X.Y.Z-RCN}}} + 1. Set environment variable version for later steps. {{{export version=X.Y.Z-RCN}}} - 1. Set the release date for X.Y.Z to the current date in each CHANGES.txt file in branch-X.Y.Z and commit the changes. {{{ + 1. Set the release date for X.Y.Z to the current date in each CHANGES.txt file in branch-X.Y.Z and commit the changes. + {{{ - git commit -a -m "Set the release date for $version"}}} + git commit -a -m "Set the release date for $version" + }}} - 1. Tag the release candidate: {{{ + 1. Tag the release candidate: + {{{ - git tag -s release-$version -m "Release candidate - $version"}}} + git tag -s release-$version -m "Release candidate - $version" + }}} - 1. Push branch-X.Y.Z and the newly created tag to the remote repo. + 1. Push branch-X.Y.Z and the newly created tag to the remote repo. - 1. Deploy the maven artifacts, on your personal computer. (You might want to do this in private and clear your history file as your gpg-passphrase is in clear text) {{{ + 1. Deploy the maven artifacts, on your personal computer. (You might want to do this in private and clear your history file as your gpg-passphrase is in clear text) + {{{ - mvn clean deploy -Psign,src,dist -DskipTests -Dgpg.passphrase=<your-gpg-passphrase>}}} + mvn clean deploy -Psign,src,dist -DskipTests -Dgpg.passphrase=<your-gpg-passphrase> + }}} - 1. Use [[https://builds.apache.org/job/HADOOP2_Release_Artifacts_Builder|this Jenkins job]] to build the artifacts + 1. Use [[https://builds.apache.org/job/HADOOP2_Release_Artifacts_Builder|this Jenkins job]] to build the artifacts - 1. Check that release file looks ok - e.g. install it and run examples from tutorial. + 1. Check that release file looks ok - e.g. install it and run examples from tutorial. - 1. Generate the checksums of the release file. {{{ + 1. Generate the checksums of the release file. + {{{ gpg --print-mds hadoop-${version}-src.tar.gz > hadoop-${version}-src.tar.gz.mds - gpg --print-mds hadoop-${version}.tar.gz > hadoop-${version}.tar.gz.mds}}} + gpg --print-mds hadoop-${version}.tar.gz > hadoop-${version}.tar.gz.mds + }}} - 1. Sign the release {{{ + 1. Sign the release + {{{ gpg --armor --output hadoop-${version}-src.tar.gz.asc --detach-sig hadoop-${version}-src.tar.gz - gpg --armor --output hadoop-${version}.tar.gz.asc --detach-sig hadoop-${version}.tar.gz}}} + gpg --armor --output hadoop-${version}.tar.gz.asc --detach-sig hadoop-${version}.tar.gz + }}} - 1. Copy release files to a public place. {{{ + 1. Copy release files to a public place. + {{{ ssh people.apache.org mkdir public_html/hadoop-${version} scp -p hadoop-${version}.tar.gz* people.apache.org:public_html/hadoop-${version} }}} - 1. Log into [[https://repository.apache.org|Nexus]], select {{{Staging}}} from the left navigation pane, right-click on the pushed repository, and {{{close}}} the release. + 1. Log into [[https://repository.apache.org|Nexus]], select "{{{Staging}}} Repositories" from the left navigation pane, select the check-box against the specific hadoop repository, and {{{close}}} the release. - 1. Call a release vote on common-dev at hadoop.apache.org. [[https://www.mail-archive.com/common-dev@hadoop.apache.org/msg13339.html|Example]] + 1. Call a release vote on common-dev at hadoop.apache.org. [[https://www.mail-archive.com/common-dev@hadoop.apache.org/msg13339.html|Example]] = Publishing = + In 5 days if [[http://hadoop.apache.org/bylaws#Decision+Making|the release vote passes]], the release may be published. - In 5 days if [[http://hadoop.apache.org/bylaws#Decision+Making|the release vote passes]], the release may be published. - 1. Update the release date in CHANGES.txt of trunk, branch-X, branch-X.Y to reflect the one in branch-X.Y.Z. Commit and push those changes. {{{ + 1. Update the release date in CHANGES.txt of trunk, branch-X, branch-X.Y to reflect the one in branch-X.Y.Z. Commit and push those changes. + {{{ - git commit -a -m "Set the release date for X.Y.Z"}}} + git commit -a -m "Set the release date for X.Y.Z" + }}} - 1. Tag the release: {{{ + 1. Tag the release: + {{{ - git tag -s release-X.Y.Z -m "Hadoop X.Y.Z release"}}} + git tag -s release-X.Y.Z -m "Hadoop X.Y.Z release" + }}} - 1. Copy release files to the distribution directory + 1. Copy release files to the distribution directory - 1. Check out the corresponding svn repo if need be {{{ + 1. Check out the corresponding svn repo if need be + {{{ svn co https://dist.apache.org/repos/dist/release/hadoop/common/ hadoop-dist }}} - 1. Generate new .mds files referring to the final release tarballs and not the RCs + 1. Generate new .mds files referring to the final release tarballs and not the RCs - 1. Copy the release files to hadoop-dist/hadoop-${version} + 1. Copy the release files to hadoop-dist/hadoop-${version} - 1. Update the symlinks to current2 and stable2. The release directory usually contains just two releases, the most recent from two branches. + 1. Update the symlinks to current2 and stable2. The release directory usually contains just two releases, the most recent from two branches. - 1. Commit the changes {{{ + 1. Commit the changes + {{{ svn ci -m "Publishing the bits for release ${version}" }}} - 1. In [[https://repository.apache.org|Nexus]], effect the release of artifacts by selecting the staged repository and then clicking {{{Release}}} + 1. In [[https://repository.apache.org|Nexus]], effect the release of artifacts by selecting the staged repository and then clicking {{{Release}}} - 1. Wait 24 hours for release to propagate to mirrors. + 1. Wait 24 hours for release to propagate to mirrors. - 1. Edit the website. + 1. Edit the website. - 1. Checkout the website if you haven't already {{{ + 1. Checkout the website if you haven't already + {{{ svn co https://svn.apache.org/repos/asf/hadoop/common/site/main hadoop-common-site }}} - 1. Update the documentation links in {{{author/src/documentation/content/xdocs/site.xml}}}. + 1. Update the documentation links in {{{author/src/documentation/content/xdocs/site.xml}}}. - 1. Update the release news in {{{author/src/documentation/content/xdocs/releases.xml}}}. + 1. Update the release news in {{{author/src/documentation/content/xdocs/releases.xml}}}. - 1. Update the news on the home page {{{author/src/documentation/content/xdocs/index.xml}}}. + 1. Update the news on the home page {{{author/src/documentation/content/xdocs/index.xml}}}. - 1. Copy the new release docs to svn and update the {{{docs/current}}} link, by doing the following: {{{ + 1. Copy the new release docs to svn and update the {{{docs/current}}} link, by doing the following: + {{{ - tar xvf /www/www.apache.org/dist/hadoop/core/hadoop-${version}/hadoop-${version}.tar.gz + tar xvf /www/www.apache.org/dist/hadoop/core/hadoop-${version}/hadoop-${version}.tar.gz cp -rp hadoop-${version}/share/doc/hadoop publish/docs/r${version} rm -r hadoop-${version} rm current2 current ln -s r${version} current2 ln -s current2 current }}} - 1. Similarly update the symlinks for stable if need be. + 1. Similarly update the symlinks for stable if need be. - 1. Add the documentation changes. {{{ + 1. Add the documentation changes. + {{{ svn add publish/docs/r${version} }}} - 1. Regenerate the site, review it, then commit it. {{{ + 1. Regenerate the site, review it, then commit it. + {{{ ant -Dforrest.home=$FORREST_HOME -Djava5.home=/usr/local/jdk1.5 firefox publish/index.html svn commit -m "Updated site for release X.Y.Z." }}} - 1. Send announcements to the user and developer lists once the site changes are visible. + 1. Send announcements to the user and developer lists once the site changes are visible. - 1. In Jira, ensure that only issues in the "Fixed" state have a "Fix Version" set to release X.Y.Z. + 1. In Jira, ensure that only issues in the "Fixed" state have a "Fix Version" set to release X.Y.Z. - 1. In Jira, "release" the version. Visit the "Administer Project" page, then the "Manage versions" page. You need to have the "Admin" role in Hadoop Core's Jira for this step and the next. + 1. In Jira, "release" the version. Visit the "Administer Project" page, then the "Manage versions" page. You need to have the "Admin" role in Hadoop Core's Jira for this step and the next. - 1. In Jira, close issues resolved in the release. Disable mail notifications for this bulk change. + 1. In Jira, close issues resolved in the release. Disable mail notifications for this bulk change. = See Also = - * [[http://www.apache.org/dev/release.html|Apache Releases FAQ]]
