Commit b03a6ed0 authored by Simon Eugster's avatar Simon Eugster

Docs: Describe branching model and release cycle, add links to KF5 and Qt5

parent 78d0ce91
# Coding and Resources
* [All Qt5 classes][qt5c]
* Qt5
* [All Qt5 classes][qt5c]
* [Signals and Slots][qt-sig]
* [MLT introduction][mlt-intro].
* [The KDE Frameworks][kf]
## Configuration
......@@ -28,3 +31,5 @@ KdenliveSettings::setLogscale(true);
[sett]: ../src/kdenlivesettings.kcfg
[mlt-intro]: https://www.mltframework.org/docs/framework/
[qt5c]: https://doc.qt.io/qt-5/classes.html
[qt-sig]: https://doc.qt.io/qt-5/signalsandslots.html
[kf]: https://api.kde.org/frameworks-api/frameworks-apidocs/frameworks/index.html
......@@ -4,8 +4,32 @@
* Get it reviewed
* Join the Telegram group
## 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.
* `feature/*` contains feature branches. When you start coding a new feature,
do it on a feature branch. When it is ready, the feature 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
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment