1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
# Contributing to Kdenlive
* Create a merge request on GitLab
* Get it reviewed
* Join the Matrix group #kdenlive-dev:kde.org
## Coding Guidelines
* Use existing code style
* Write unit tests
* Document unclear parts (e.g. what a QMutex is locking)
## Release + Branching Model
Kdenlive is following the [KDE Release Schedule][sched] and a new major version
like `20.04` is released every four months. Bugfix releases like `20.04.1` are
released until the next major release arrives.
The branching model in Git works as follows:
* `master` is the most recent development version.
* `release/*` contains release branches like `release/20.04`. Shortly before a
new major version is released, the new release branch is created and we enter
feature and string freeze for final bugfixes and translation of texts. The
version which is effectively released is marked with a tag.
* `work/*` contains work branches. When you start coding a new feature,
do it on a work branch. When it is ready, the work branch is merged
back into master if the merge request has been approved.
Bugfixes for the released versions are added on the release branch and then
merged back to master.
[sched]: https://community.kde.org/Schedules
|
