Think about and draft a good release process based on a discussion with the team. (The proposal does not need to satisfy everyone on the team, but take everyone's input into account and possibly discuss why you did or did not follow some points) (Make sure the proposal is in-line with git flow)

Look at other projects' release processes (e.g. GitLab).

Outcome: PR to developer guidelines.

There is some written form that presents an improved proposal with an argumentation why the proposal was made the way it was.

Below is a proposal to get you started:

1. time-based releases
2. on develop we start 0.x.0-alpha.1 version numbers
3. at fixed time intervals, we move develop to release-0.x branch where the version moves to 0.x.0-beta.1
4. from the release branch, we integrate in JLP, and/or later OST Platform;
5. upon success beta-testing, we organize external security assessments
6. releases that have been reviewed by external experts get 0.x.0-rc.1 tags, following review corrections
7. on release day (on regular interval or following other scheduled plans), release branch is moved to master and tagged as 0.x.0
8. later fixes on the release increase the patch number on the release branch, and are merged to master