We are using git as a versioning system using the Git Branching Workflows.
There is some discussion in the global community that this is hindering continuous integration but we like to have a develop branch to, e.g. catch issues before they go into production.
Because we have a fast workflow and merge there often it works pretty well and is "continuous" enough for our purposes.
- 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
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.
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