E Version handling processes

This page summarizes the version handling processes for all Autonomous function development. The version handling tool is Github. The process includes the following subprocesses:

1. Repository handling strategy
2. Branching strategy
3. Master repo - subrepo strategy
4. Release concept
5. Tagging concept

Initial state of repositories

Different ROS nodes exist, mostly in separate repositories. Each repository contains given type of software functionality, mostly developed by separate persons. In certain cases, one repository contains the work of multiple persons. The developed functionalities / ROS node means a software component, which cannot be used on its own. Therefore it is necessary to know which function we shall use the given component (component = e.g. sensing, function = e.g. parking mission).

Branching strategy

Component repositories must at least contain a release branch, a development branch and occasionally one or more feature branches.

1. The parking trajectory planner repository contains a stable, working version of the software on the development branch.
2. A bug fix / new feature development task must be done. For this, a side branch is created either under feature/xxx or bugfix/xxx with a meaningful name.
3. The development happens on this side branch and continuously validated through simulation / unit tests.
4. Once the development is considered to be done, the changes are merged to development branch (side branch can be deleted). This can happen via a pull request (PR) which contains source -> target branches, commit summaries, comments..etc. A reviewer person must be added (note: repository can be set to accept merges through PR-s only). If PR is reviewed, it can be merged.
5. Once the component is test with all changes, it can be merged to release branch (either via PR or simple way).

Tagging concept

The component development repository must contain a release branch, which must contain software with the following tags:

1. test_vX.Y - a status of the component, which is tested on component level, reviewed and considered to be stable and ready for functional testing
2. release_vX.Y - a status of the component, which is tested on functional level (in vehicle), considered to be stable and validated.

Repository handling strategy and release concept

We must develop a given component in its own repository. E.g. lane edge detection which takes inputs from sensing and returns outputs to planner is a separate ROS node, which is included in the szenergy_parking_challenge repository. The developer(s) of this component must work in this repository.

---

If we want to develop / integrate a functionality (e.g. parking mission) we must establish a master repository (parking_master_repo) with the naming convention of xxx_master_repo. This repository is not a developer repository, therefore it shall not directly contain code under development. It can only contain documentation (or other description file) which is valid for the entire functionality. The master_repo must include submodules /subrepos of ALL component repositories which is needed for the given functionality. A master_repo is good, if somebody wants to use this functionality, he/she can only pull the master repo, and a stable, valid version of the software will be present on his/her computer. There must be one nominated responsible for the given master_repo who ensures valid subrepo structure all the time. The master repo must contain one branch only! Submodules must be added to the root folder of the master repo.

---

The submodule pointers must point to specific tags. Before a functional test occurs, it must be validated in simulation environment. At this stage, at least one submodule must be in test status. When the simulation validation occurred for the functional level, the master repo must be given a functest_vX.Y tag and used during vehicle testing. Once the functional changes are done on component level, and the functionality is validated on vehicle level, the component commits must be given release_vX.Y tag, this tag must be pulled in the master repo, and the master repo must be given a funcrelease_vX.Y. From this point on this latest tag is considered to be the most complete, stable version of the entire function.