...
- Notify developers on the mailing list that you are about to branch a release.
Create a branch for the release series:
Code Block git clone -b master https://git-wip-us.apache.org/repos/asf/zookeeper.git # 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 commitpush <remote> -m "Preparing for release branch-X.Y.Z"
Checkout master branch.
Code Block git push <remote> branch-X.Ycheckout master
- Update the default version in build.xml on master to X.Y+1.0-SNAPSHOT.
- Update the version number in src/c/configure.ac and src/c/include/zookeeper_version.h to be X.Y+1.0.
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/configure.ac 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
...
Check out the branch with:
Code Block git clone -b branch-X.Y https://git-wip-us.apache.org/repos/asf/zookeeper.git
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 m
erge
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>
- 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.
- 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.
- Update the version number in build.xml to be ''X.Y.Z''
- Update the version number in src/c/include/winconfig.h, src/c/configure.ac, and src/c/include/zookeeper_version.h to be ''X.Y.Z''
- Update the copyright years in NOTICE.txt if it's outdated.
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
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
...