Page History

...

1. Check out the branch with:

   Code Block
   git clone -b branch-X.Y https://git-wip-us.apache.org/repos/asf/zookeeper.git

2. If you are creating a point release (almost always the case) then follow this step. The exception to this is typically only when creating a new release candidate because the previous candidate failed during voting (rc0 failed and you are creating rc1+) – in which case skip this step.
   
   

   Create a branch for X.Y.Z (the current release candidate)

   Code Block
   git branch branch-X.Y.Z git push <remote> branch-X.Y.Z

   
   Update the version number in build.xml, src/c/configure.ac, src/c/CMakeLists.txt, and src/c/include/zookeeper_version.h to the next logical SNAPSHOT version (e.g. X.Y.Z to X.Y.(Z+1)-SNAPSHOT)
   
   Commit this change.

   Code Block
   # check for modified files git status # add modified files one by one git add <modified files>   # commit and push the changes to remote repo branch-X.Y git commit -m "Prepare for the next release: update the version to X.Y.(Z+1)-SNAPSHOT" git push <remote> branch-X.Y

3. Checkout the active point release branch - this is where you will be creating the release candidate

   Code Block
   git checkout branch-X.Y.Z

   
   

4. If not already done, cherry-pick desired commits from master into branch-X.Y. You can find the revision hash using git log in the .Z. If cherry-picks are done from other than branch-X.Y and in master. Then cherry-pick each commit from the remote master into the ensure that those changes are also committed to branch-X.Y individually (again in order). If there are conflicts, then it is preferable to produce a new patch for this branch, review it separately and commit it via JIRA. Please refer HowToContribute and Committing changes page for pushing changes to the project. 

   Code Block
   # The -x option records the source commit, and reuses the original commit message git cherry-pick -x <commit-hash>

5. Do a final pass regeneration of docs by running "ant -Dforrest.home=<path to Forrest> clean docs".  If there are any modifications, then they'll show up under the docs folder.  If there are any changes, then commit them.  However, DO NOT commit changes in docs/releasenotes.html or docs/releasenotes.pdf.  (Release notes are handled in a separate step.)  Release notes should be regenerated each time a documentation patch is committed.  This final pass before the release is intended to catch mistakes in case this step was missed at commit time.
6. Update docs/releasenotes.html with release notes for this release. You can get the HTML by following the "Release Notes" link for the relevant release on the https://issues.apache.org/jira/browse/ZOOKEEPER?report=com.sourcelabs.jira.plugin.portlet.releases:releases-projecttab#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel tab in Jira. Note that you need to exclude the won't fix or invalid tickets.
7. Update the version number in build.xml to be ''X.Y.Z'' (i.e. remove SNAPSHOT designator)
8. Update the version number in src/c/configure.ac, src/c/CMakeLists.txt, and src/c/include/zookeeper_version.h to be ''X.Y.Z''
9. Update the copyright years in NOTICE.txt if it's outdated.

10. Commit these changes.

    Code Block
    # check for modified files git status # add modified files one by one git add <modified files>   # commit and push the changes to remote repo branch-X.Y git commit -m "Preparing for release X.Y.Z" git push <remote> branch-X.Y.Z

11. Tag the release candidate (R is the release candidate number, and starts from 0):

    Code Block
    # create a signed tag git tag -s release-X.Y.Z-rcR -m "ZooKeeper X.Y.Z-rcR release."   # push the newly created rc tag to the remote repo. git push <remote> release-X.Y.Z-rcR

...