User Tools

Site Tools


for_developers:bugfixprocess

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

for_developers:bugfixprocess [2019/01/31 17:19] (current)
kunz Created
Line 1: Line 1:
 +====== Bug Fix Release Process ======
 +
 +**NOTE : This process is in its early stage and not yet tested.**
 +
 +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 [[http://​eeros.org/​contact/​|contact form]].
 +
 +==== 1. Announcement of a bug fix release ​ ====
 +
 +On the **[[https://​trello.com/​b/​9nLSxZ0B/​eeros-tasks|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.
 +
 +
 +==== 2. Search of the oldest related active release ​ ====
 +
 +The oldest related active release must be searched. The following git command will help.
 +
 +<​code>​
 +git branch --list v*
 +</​code>​
 +
 +
 +==== 3. Creation of a bug fix branch and implement the bug fix  ====
 +
 +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).
 +
 +<​code>​
 +git checkout -b hotfix_issue42 v1.0 
 +</​code>​
 +
 +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.
 +
 +
 +==== 4. Apply the bug fix  ====
 +
 +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. ​
 +
 +<​code>​
 +git checkout v1.0
 +git merge hotfix_issue42 --no-ff ​
 +</​code>​
 +
 +
 +==== 5. Update the change log and create the release commit ​ ====
 +
 +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 [[https://​keepachangelog.com/​en/​1.0.0/​|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:
 +
 +<​code>​
 +git add *CHANGELOG.md*
 +git commit -m "Bug Fix Release v1.0.0"​
 +git push
 +</​code>​
 +
 +
 +==== 6. Publish the new release on GitHub ​ ====
 +
 +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.
 +
 +{{:​for_developers:​release_v1.0.0_github_1.png?​nolink|}}
 +
 +Note that the information in the description section is copied from the change log.
 +
 +
 +==== 7. Merge the bug fix into the newer release branches ​ ====
 +
 +The bug fix must be applied on all newer releases 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.
 +
 +<​code>​
 +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!
 +</​code>​
 +
 +
 +==== 8. Update of the Jenkins items for the bug fix  ====
 +
 +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.
 +
 +
 +==== 9. Creation of a new card to discuss suggestions for improvement ​ ====
 +
 +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.
 +
  
for_developers/bugfixprocess.txt · Last modified: 2019/01/31 17:19 by kunz