Page History

...

• Update CHANGES.txt in master to replace  Release X.Y.0 (unreleased changes) with Release X.Y.0 - YYYY-MM-DD. Commit:

  No Format
  git commit -m "Preparing for release X.Y.Z"

  
  

• Create a branch for the release series:

  No Format
  git checkout -b branch-X.Y.Z origin/master

  
  

• Add A.B.C-SNAPSHOT (unreleased changes) to CHANGES.txt in master.

• Bump the version number in the master branch:

  No Format
  ./gradlew setversion -Pnextversion="A.B.C-SNAPSHOT"

  
  

• Commit these changes to the master and push.

• Checkout the release branch

  No Format
  git checkout branch-X.Y.Z

  
  

• 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 to 0.8.0.

  No Format
  ./gradlew setversion -Pnextversion="X.Y.Z"

  
  

• Commit these changes to the release branch and push

  No Format
  git commit -m "Changing version to X.Y.Z"

  
  

• Rename docker images and repo URLs:

  No Format
  grep -R --color :trunk- * |grep yaml grep -R --color "http://repos.bigtop.apache.org/releases/1.3.0" *

  
  

• 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.

...