The following is a step-by-step procedure for releasing a new version of EEROS.

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, a new card must be created in the list Releases. It is recommended to use the copy function on the template card. The card must be named with the version name of the new release. EEROS is versioned according to the Semantic Versioning Specification. The card of the first major version as an example is named with v1.0.0.

The card must be filled with the following information, which is also included in the template card:

1. Release notes in the description section.
   1. New features
   2. Bugfixes
   3. Other changes and improvements
2. Checklist with at least the entries given in the template card.
3. At least 3 board members must be added to the card.

The next step is to go through all cards which are labelled with the version number of the new release. It is recommended to use the search functionality (for example search for all cards with label Release 1.0 in list General ⇒ #“Release 1.0” list:General). The cards which are not in the Done list must either be relabelled with the label of the next version number or closed. The most reasonable solution is to comment the card and mention the responsible user by using the @username annotation.

This step should lead to a discussion on the card. The card members have to decide, if the code base is ready for the release or not. This step is finished as soon as all card members agree.

The steps 2-4 below can be done during the discussion phase since they will overlap with each other.

The EEROS release workflow supports multiple active releases. Therefore, every release is created on a release branch. The name of the release branch contains the MAJOR.MINOR part of the release number. The release tags contain the full pattern.

Since the development is done on the master branch, the release branch is created based on the HEAD of the master branch. The following git commands will create the new release branch (release/1.0 is used as an example):

git checkout -b release/1.0 master

The new branch is pushed to the remote repository, which is the one on Github. The remote repository does not know the new branch yet. It can be set by the following git command:

git push --set-upstream origin release/1.0

After the creation of the new release branch, the code must be stabilised. Tests with different setups and compilers are the most of the time necessary. At least one item has to be added on the Jenkins server. How this is done is described on the Creation of Jenkins item page. This item must at least build EEROS with cmake and run all unit tests. An example is found here.

The new release branch 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 or new features, they are done in this step.

The API documentation is generated by Doxygen and must be fully inspected. Any changes made since the last release must be read and reviewed.

If there are any issues, they must be fixed. If this is not possible without major changes, a workaround is implemented which will be resolved until the next release.

Before starting this step, steps 1-4 must be completed.

The release branch is ready. The final commit must only contain the change of the version number in the main CMakeLists.txt file.

The version information is changed as shown below (release v1.0.0 is used as an example).

.....
set(EEROS_VERSION_MAJOR 1)
set(EEROS_VERSION_MINOR 0)
set(EEROS_VERSION_PATCH 0)
set(EEROS_VERSION ${EEROS_VERSION_MAJOR}.${EEROS_VERSION_MINOR}.${EEROS_VERSION_PATCH})
....

Now, the change is committed and pushed to the EEROS repository on Github. The commit must contain the following message: release/1.0.0. This is done by the following git commands:

git add *CMakeLists.txt*
git commit -m "release/1.0.0"
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.

insert picture

Since there were new commit on the release branch only, they must be merged into the master branch. This ensures that the master contains all commits. This is achieved by the following git commands.

git checkout master
git merge release/1.0

The normal development is continued on the master during the creation of a new release. Since the new release is published, the current version on the master branch is now a snapshot of the next version. Therefore, the version information must be changed in the main CMakeLists.txt file as shown below (release v1.0.0 was released as an example).

.....
set(EEROS_VERSION_MAJOR 1)
set(EEROS_VERSION_MINOR 0)
set(EEROS_VERSION_PATCH 0)
set(EEROS_VERSION ${EEROS_VERSION_MAJOR}.${EEROS_VERSION_MINOR}.${EEROS_VERSION_PATCH}-snapshot)
....

The change is committed and pushed.

The second last step is to update the API documentation on the EEROS Website. The HTML files are generated with Doxygen. The following command is issued, to start Doxygen:

... eeros-framework/buildFolder$ doxygen Doxyfile

The documentation is found at the path eeros-framework/buildFolder/doc/html. The HTML documentation is uploaded as described below:

describe upload.

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