Bug Fix Release Process

The following is a step-by-step procedure for creating a bug fix release.

All the planning work is done on Trello on the EEROS Tasks Board. New developers have to request access rights by submitting the contact form.

On the EEROS Tasks Trello Board, all release cards must be updated on which the bug fix will be applied. The card names must be updated with the new version name. For example, a bug fix for v1.0 is described in card v1.0 and the card name changed to v1.0.1.

The cards must be updated with all the information about the bug fix in the description section. A Fixes title must be created. It must be clear which fix was made in which version. This can be achieved with the version name in the Fixes title. For example Fixes (v1.0.1).

This step should lead to a discussion on the card. This step is finished as soon as all card members agree.

The oldest related active release must be searched. The following git command will help.

git branch --list v*

The bug fix is implemented in a separate branch. The following git command will create the branch. Note that the new branch must be created from the oldest related active release branch (for example v1.0).

git checkout -b hotfix_issue42 v1.0 

The bug fix is implemented on this branch.

The changed code must be stabilised. Intensive testing is now necessary. The Jenkins server helps during this phase by enabling various tests with different compilers and setups. If tests are necessary on specific hardware due to changes, they are done in this step.

Once the code is stable, the bug fix is applied by merging the bug fix branch into the release branch with the following git commands.

git checkout v1.0
git merge hotfix_issue42 --no-ff 

Afterwards, the change log file is updated and finalized. The change log must contain the following:

• Section for Fixed, Security things
• The latest version comes first
• The release date of the Release
• Link to GitHub compare feature which compares to the last release (show the changes)

The style should always match the previous entries and is base on this guidelines.

The release branch is ready. The final commit must only contain changes in the CHANGELOG.md file.

Now, the change is committed and pushed to the EEROS repository on GitHub. The commit must contain the following commit message: Bug Fix Release v1.0.1. Of course, the right version number must be used. This is done by the following git commands:

git add *CHANGELOG.md*
git commit -m "Bug Fix Release v1.0.1"
git push

The final commit was pushed to the repository on GitHub. It is important, that the release tag is set on the GitHub Website. GitHub provides a feature which will show special tags as releases.

The release tag is created by completing the form, which can be reached via the following link:

https://github.com/eeros-project/eeros-framework/releases/new

It is very important, that the right release branch is selected. The form must be completed as shown in the picture below.

Note that the information in the description section is copied from the change log.

The bug fix must be applied on all newer releases and finally on the master branch too. Therefore, the bug fix must be merged upwards through all releases (merge cascade). After each merge, the change log is updated on the corresponding release branch and a release tag created. Basically, the steps 5 and 6 must be executed.

The following git commands show the procedure for one cascade. It must be repeated.

git checkout v1.3
git merge v1.0
git add *CHANGELOG.md*
git commit -m "Bug Fix Release v1.3.1"
# the tag is created on GitHub!

After the bug fix is applied, all Jenkins items of the corresponding versions must be updated if necessary. If the Jenkins items check out the release branch, no change is probably needed since the bug fix is applied on the release branches.

This optional step provides the possibility to improve the bug fix process. On the EEROS Tasks Trello Board, a new card is created in the list General. This card is filled with suggestions for improvement.