...
Update CHANGES.txt in master to replace
Release X.Y.0
(unreleased)Release X.Y.0 - YYYY-MM-DD
. Commit:Code Block language bash git add CHANGES.txt git commit -m "Preparing for release X.Y.0"
Create a branch for the release series:
Code Block language bash git checkout -b branch-X.Y origin/master
Switch back to master and add
A.B.C-SNAPSHOT (unreleased changes)
to CHANGES.txt.Code Block language bash git checkout - (edit CHANGES.txt)
Bump the version number in the master branch:
Code Block language bash ./gradlew setversion -Pnextversion="A.B.C-SNAPSHOT"
Commit these changes to the master and push.
Code Block language bash git add CHANGES.txt (and other updated files) git commit -m "Bumping up the version to A.B.C-SNAPSHOT" git push upstream master (assuming that ASF repo is referred to as 'upstream')
Checkout the release branch
Code Block language bash git checkout branch-X.Y
Update the release branch's version information: the version number in the release branch ends in
-SNAPSHOT
, but we need to remove this for the release. For example,0.8.0-SNAPSHOT
needs to be changed to0.8.0
.Code Block language bash ./gradlew setversion -Pnextversion="X.Y.Z"
Rename docker images and repo URLs:
Code Block language bash grep -R --color :trunk- * | grep yaml grep -R --color "http://repos.bigtop.apache.org/releases/X.Y.Z" * grep -R --color "http://repos.bigtop.apache.org/releases/x.y.z" * (where "x.y.z" is the previous version of "X.Y.Z". Just in case) (replace the occurrences found by the above commands)
Commit these changes to the release branch and push
Code Block language bash git add (updated files) git commit -m "Changing version to X.Y.Z" git push upstream branch-X.Y (assuming that ASF repo is referred to as 'upstream')
Also, update the default version of Bigtop (and your code signing key ID, if needed) defined in hieradata on master and the release branch. For example:
Code Block language bash $ git checkout master (edit bigtop-deploy/puppet/hieradata/bigtop/repo.yaml) $ git diff diff --git a/bigtop-deploy/puppet/hieradata/bigtop/repo.yaml b/bigtop-deploy/puppet/hieradata/bigtop/repo.yaml index 48c8a4ae..0d6a9126 100644 --- a/bigtop-deploy/puppet/hieradata/bigtop/repo.yaml +++ b/bigtop-deploy/puppet/hieradata/bigtop/repo.yaml @@ -1,5 +1,5 @@ bigtop::bigtop_repo_gpg_check: true -bigtop::bigtop_repo_apt_key: "BB95B97B18226C73CB2838D1DBBF9D42B7B4BD70" +bigtop::bigtop_repo_apt_key: "01621A73025BDCA30F4159C62922A48261524827" bigtop::bigtop_repo_yum_key_url: "https://downloads.apache.org/bigtop/KEYS" -bigtop::bigtop_repo_default_version: "1.4.0" +bigtop::bigtop_repo_default_version: "1.5.0" $ git add bigtop-deploy/puppet/hieradata/bigtop/repo.yaml $ git commit -m "Update default values in hieradata for release 1.5.0" [master 9715ca7a] Update default values in hieradata for release 1.5.0 1 file changed, 2 insertions(+), 2 deletions(-) $ git push upstream master $ git checkout branch-1.5 $ git cherry-pick -x 9715ca7a $ git push upstream branch-1.5
- Shall you need to commit additional fixes into ongoing release, the commits should go to the release branch and only then be merged into master. Doing this other way around forces
git cherry-pick
which leads to discrepancies in the commit hash-codes and makes the branch look untidy and hard to follow.
For a patch release, just do the following three items on the branch-X.Y, instead of doing all of the items above:
- Update the release branch's version information
- Rename docker images and repo URLs
- Commit these changes to the release branch and push
3. Generate the Release Notes
...