Introduction
The development and release process is supported by a structured process with the code organized in a number of GitHub repositories (see Project Structure).
A dedicated decision was taken to keep the code organized in a parent repository with independent submodules, where the parent mainly carries the documentation for all repositories. This structure allows deploying frontend and backend independently, while, e.g., issues can be exchanged between the repositories.
The server-setup repository runs on a single branch (development) and is not versioned, as it maintains only the ansible code. Feature branches can/should be created for major changes
The repositories carrying the developed code for frontend and backend (Strapi) use two branches: development for active work and production for stable releases. Versions are tracked through GitHub release tags (v1.2.7, v1.1.8) always created on the production branch after a squash merge from development.
Build strategy change (April 2026)
After the security incident, builds on the production server were eliminated entirely. The staging server now builds all Docker images; production only receives finished images via SSH transfer. See the Deployment Process for details.
In order to keep the release information and commit structure well organized it is aspired to:
- create an issue for every requested/required change, split in sub issues where necessary
- create a commit for every issue solved, allowing e.g. cherry-picking of releases
- create a release referencing all issues resolved within it
INFO
Release Template
### 🎉 New Functionality
### ⏫ Enhancements
### 🐛 Bugfixes
### 🔥 Breaking Changes
### 🏁 To-do after Release
### 📚 DocumentationA loose versioning rule is used differentiating Functional Releases (adding new functionality) and Patch Releases (combining a number of bug fixes minor enhancements) and more or less urgent Hot Fixes (bug fixes on production). For Hot Fixes are represented by a single commit in development and production branch in parallel