Skip to content

Release Workflow Steps

Jump to bottom
ermshiperete edited this page Nov 28, 2012 · 10 revisions

If you're not working on a release-related branch you might rather want to look at the workflow step by step page.

Table of Contents

Creating a Release Branch=

When it’s time to prepare a new release we create a new release branch. This creates a new branch release/1.1.

Open Git Gui, select Tools-->Release-->Start. As argument pass the name of the release: 1.1

Alternatively on the command line: 

    $ git flow release start 1.1

Note: Before anyone can submit changes on this branch for code review on Gerrit, someone in Gerrit’s Administrator group needs to create the release/1.1 branch on Gerrit (Branch Name: release/1.1, Initial Revision: develop).

Sharing a Release Branch

To share a release branch so that others can contribute, you can publish the release branch. This pushes the branch release/1.1 to the remote repo.

Open Git Gui. If necessary switch to the release branch (Branch-->Checkout), then select Tools-->Release-->Publish.

Alternatively on the command line: 

    $ git flow release publish 1.1

Note: Depending on the permissions in Gerrit publishing a release might not be possible until an administrator first creates the release branch in Gerrit (Branch Name: release/1.1, Initial Revision: develop).

Joining work on a Release Branch

If someone else already started a release branch and you want to join development on the release branch, you need to track the release branch on the remote repo. This pulls the branch release/1.1 from the remote repo and sets it up as tracking branch.

Open Git Gui, select Tools-->Release-->Track. As argument pass the name of the release: 1.1

Alternatively on the command line: 

    $ git flow release track 1.1

Fixing Bugs in Release Branch

Then work on any necessary bug fixes in the release branch. When your changes are ready for code review push them to Gerrit. (If you get an error message “remote rejected” then probably the release branch hasn’t been created in Gerrit.)

Open Git Gui, select Tools-->Release-->Submit for Code Review.

Alternatively on the command line: 

    (release/1.1) $ git review release/1.1

Releasing the New Version

When you’re ready for release, the changes from the release branch need to be merged into the master and develop branches. First, make sure all pending changes for the release branch are either merged or abandoned in Gerrit. Then do the following:

Open Git Gui. If necessary switch to the Release branch (Branch-->Checkout), then select Tools-->Release-->Finish.

Alternatively on the command line: 

    (release/1.1) $ git release 1.1

This syncs the develop and master branches with the remote repo, merges release/1.1 into master and develop, creates a tag 1.1 on master and eventually pushes the branches and tag to the remote repo.

Hotfixes

Sometimes it is necessary to fix bugs for the latest already released version (1.1). The fixed version will be called 1.1.1. The expectation is that only few people work on this hotfix over a fairly short amount of time. Therefore we don’t create a separate branch on the remote repo. A hotfix is always for the latest released version.

Creating a Hotfix Branch

Open Git Gui, select Tools-->Hotfix-->Start. As argument pass the name of the fixed version: 1.1.1

Alternatively on the command line: 

    $ git flow hotfix start 1.1.1

This will create a new branch hotfix/1.1.1 based on master.

Fixing Bugs in Hotfix Branch

Then work on the bug fixes in the hotfix branch. When your changes are ready for code review push them to Gerrit:

Open Git Gui, select Tools-->Hotfix-->Submit for Code Review.

Alternatively on the command line: 

    (hotfix/1.1.1) $ git review master

Releasing the Patched Version

When the hotfix is ready, the changes from the hotfix branch need to be merged into both master and develop:

Open Git Gui. If necessary switch to the Hotfix branch (Branch-->Checkout), then select Tools-->Hotfix-->Finish.

Alternatively on the command line: 

    (hotfix/1.1.1) $ git hotfin 1.1.1

This syncs the develop and master branches with the remote repo, merges hotfix/1.1.1 into master and develop, creates a tag 1.1.1 on master and eventually pushes the branches and tag to the remote repo.

Fixing Older Versions

When it becomes necessary to fix a bug in an older released version, we can create a Support branch. For example suppose we recently released version 1.1 but then it’s decided that we also have to re-release 1.0 with a bugfix. The re-release will be 1.0.1.

Creating the Support Branch

The support branch will be named after the base version we’re fixing, so in this case support/1.0. We base it on the tagged version 1.0.

Open Git Gui, select Tools-->Support-->Start. As argument pass the name of the support branch (1.0) and the tag it is based on (1.0)

Alternatively on the command line: 

    $ git flow support start 1.0 1.0

This will create a new branch support/1.0 based on the tag 1.0.

We also need to create a new branch in Gerrit for the support branch support/1.0 (Branch Name: support/1.0; Initial Revision: 1.0)

Fixing Bugs in the Support Branch

Then work on the bug fixes in the support branch. When your changes are ready for code review push them to Gerrit:

Open Git Gui, select Tools-->Support-->Submit for Code Review.

Alternatively on the command line: 

    (support/1.0) $ git review support/1.0

Releasing the Patched Version

When the bugs are fixed and we can release a new version of 1.0, we have to tag the support branch and merge the changes onto the develop branch.

Open Git Gui. If necessary switch to the Support branch (Branch-->Checkout), then select Tools-->Support-->Finish. Pass the name of the new version (1.0.1) as argument.

Alternatively on the command line: 

    (support/1.0) $ git supfin 1.0.1

This syncs the develop branch with the remote repo, creates a tag 1.0.1 on the support/1.0 branch, merges support/1.0 into develop, and eventually pushes the branches and tag to the remote repo.

Clone this wiki locally