This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • HowToRelease using git

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Notify developers on the mailing list that you are about to branch a release.
  2. Create a branch for the release series:

    Code Block
    git clone -b master
    # create new branch-X.Y from master branch
    git checkout -b branch-X.Y master
    # commit and push the changesnew branch to remote repo
    git commit -m "Preparing for release X.Y.Z"
    git push <remote> branch-X.Y
  3. Checkout master branch.

    Code Block
    git checkout master
  4. Update the default version in build.xml on master to X.Y+1.0-SNAPSHOT.
  5. Update the version number in src/c/ and src/c/include/zookeeper_version.h to be X.Y+1.0.
  6. Commit these changes to master.

    Code Block
    # check for modified files
    git status
    # add individual files one by one
    git add build.xml
    git add src/c/
    git add src/c/include/zookeeper_version.h
    # commit and push the changes to remote repo
    git commit -m "Preparing for X.Y+1.0 development"
    git push <remote> master


  1. Check out the branch with:

    Code Block
    git clone -b branch-X.Y
  2. If not already done, merge cherry-pick desired patches commits from master into the into branch-X.Y and commit these changes. You can find the revision hash using git log in the branch-X.Y and in master. Then merge each cherry-pick each commit from the remote master into the branch-X.Y individually (again in order), allowing conflicts to be recorded for each commit. If there are conflicts, then resolve it manually.

    TODO: Need to document git commands to do merging and committing the changes to the branch.

    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>
  3. 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.
  4. 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 tab in Jira. Note that you need to exclude the won't fix or invalid tickets.
  5. Update the version number in build.xml to be ''X.Y.Z''
  6. Update the version number in src/c/include/winconfig.hsrc/c/, and src/c/include/zookeeper_version.h to be ''X.Y.Z''
  7. Update the copyright years in NOTICE.txt if it's outdated.
  8. 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
  9. 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