Update Workflow - OpenSlides/OpenSlides GitHub Wiki
Starting in June 2023 stable updates meant for production are no longer tagged following the scheme
4.0.1-main-YYYYMMDD-<commit_sha>
Instead they will just have tags like
4.0.14.0.2...4.0.104.0.11...4.1.1...
There will also be so-called staging updates, which contain more recent features but are still undergoing tests. Use with caution! These are tagged following the scheme
4.0.1-staging-YYYYMMDD-<commit_sha>
Each of the OpenSlides repository has two branches main and stable. All
development PRs go against the main branches. The stable branch is
unavailable for normal PRs and should only be pushed by maintainers using the
helper script dev/scripts/make-update.sh which accumulates changes into
updates. There are make targets encapsulating this script for easier access
-
services-to-main:dev/scripts/make-update.sh fetch-all-changes -
staging-update:dev/scripts/make-update.sh staging -
stable-update:dev/scripts/make-update.sh stable
The first stage of this is done by calling make staging-update which fetches a
selection of changes and creates a commit in the main repositories main branch
with updated submodule pointers. These staging updates will then undergo testing
and once they are deemed fine a stable update is created using make stable-update.
This will create merge commits in all repositories merging the tested changes
into the stable branch.
Every staging update will increment the patch number (i.e. The 3rd in the version string) with respect to the latest stable version.
If the minor version (i.e. The 2nd in the version string) is to be increased
this must be done manually when creating the staging update that will become
the new minor update. Specifically when running make staging-update before
confirming to commit changes, in a second shell edit the VERSION file to the
new minor version and git add it. A new stable/4.N.x branch must also be
created manually at the tip of stable/4.(N-1).x such that make stable-update can find and push to it.
Sometimes a stable version contains a problem which must be fixed quickly and cannot wait until the next staging cycle has completed.
In such cases the developer must create a PR that goes against the stable
branch of the affected service. After merging make hotfix-update will pick it
up and create a new stable release that only contains this change (while the
main branches may already contain other changes).
In order to also reflect this change in the main branch, a PR merging stable -> main should be opened.
Images can be built from the checked out repository using dev/docker/build.sh.
They will be automatically tagged depending on the current branch.
-
stable->4.x.x -
main->4.x.x-staging-YYYYMMDD-<commit_sha>
The tag is also injected into openslides-client/client/src/assets/version.txt
in order for the client to be able to reflect the version (on the /info page).
Builds are also automatically triggered for every commit in the main repository
via github action (see .github/workflows/build-images.yml).