Actions
Git Workflow¶
We are using git as a versioning system using the Git Branching Workflows
Branches¶
- main - the stable version used in productive environments. It is the latest release version which is tested and, to our knowledge, bug-free.
- develop - here the latest development branches are joined when they are finished.
- release_candidate - a special branch made from develop a few days before a release. This branch is frozen: no new features allowed, it's only for testing, fixing and manual updates.
- feature_ - e.g. feature_user_profile_image
- fix_ - e.g. fix_map_bug
Workflow¶
If working on a new feature/fix:
- Start with a new branch from develop and call it feature_something or fix_something if it isn't a critical problem. In case it is a critical problem start a branch from main in preparation of a fast minor release.
git checkout develop git checkout -b feature_something
- Implement changes, commit
git add . git commit -m "Implemented feature something"
- Merge develop regularly to your branch to keep merge conflicts to a minimum but at least before merging back
git merge develop
- Make sure that all tests pass, ideally have 100% coverage and Mypy checks are passing
- Document database changes (see below) and add translations if needed
- Merge your branch to develop
git checkout develop git merge feature_something
About once a month a new release_candidate branch is made from develop which, after some quality checks, is than released and merged into the main branch.
When working in the release_candidate branch please also merge it to the develop branch afterwards.
Database changes¶
If there are database changes make sure that
- there is a comment with the issue number at the SQL update script (e.g. install/upgrade/3.12.0.sql) to easier deal with installations that were already partially updated (e.g. the demo-dev version)
- the database change is noted at util/changelog.py
- the database version is added in config/database_versions.py
Updated by Alexander Watzinger 4 days ago · 21 revisions