philipp/KDDockWidgets
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

README.md - a bit of trivial whitespace cleaning

Browse Source
This commit is contained in:
Allen Winter
2022-09-13 12:06:37 -04:00
parent 77c8cec2b8
commit 619119fc37
1 changed files with 8 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
README.md
View File

@@ -5,7 +5,6 @@
> ⚠️⚠️: If you're using QtQuick/QML it's recommended to use 2.0 branch. 1.x will continue
> to receive bug fixes for a long time but only for QtWidgets frontend.
`KDDockWidgets` is a Qt dock widget library written by KDAB, suitable for replacing
`QDockWidget` and implementing advanced functionalities missing in Qt.
@@ -148,16 +147,18 @@ Please refer to [README-bindings.md](README-bindings.md).
## Versioning
There's currently two lines of development: `v1` which is very mature and stable and `v2` which is an ongoing effort to make
KDDW support multiple "frontends" (QtWidgets, QtQuick and even non-Qt technologies, like flutter).
There's currently two lines of development: `v1` which is very mature and stable and `v2` which is an
ongoing effort to make KDDW support multiple "frontends" (QtWidgets, QtQuick and even non-Qt technologies,
like flutter).
1.x will be supported for many years to come, at least for bug fixes and small features.
Use `v1.5.0` tag for the latest stable. `v1.6.0` will be released soon, so branch `1.6` is also safe.
Use `v1.5.0` tag for the latest stable. `v1.6.0` will be released soon, so branch `1.6` is also safe.
Use `2.0` if you need non-QtWidgets support, for example `QtQuick/QML`. While `1.6` has support for `QtQuick/QML` it won't be receiving bug fixes. `2.0` is under active development, you might encounter minor source/ABI incompatibilities. Despite that,
it is pretty stable, and all 200 unit-tests pass.
Use `2.0` if you need non-QtWidgets support, for example `QtQuick/QML`. While `1.6` has support for `QtQuick/QML`
it won't be receiving bug fixes. `2.0` is under active development, you might encounter minor source/ABI
incompatibilities. Despite that, it is pretty stable, and all 200 unit-tests pass.
We'll try to remain source-compatible across versions (except for the v1 -> v2 jump).
We'll try to remain source-compatible across versions (except for the v1 -> v2 jump).
API will get a deprecation notice before being removed in the next version. Note that this
compatibility effort is only for the public API. Private API (headers ending
in _p.h) might change so you shouldn't depend on them. Private API is only