User:Aspotashev

Helpful stuff:

On BIC:

KDE Vinegret 5.x

This is an RFC for a new KDE product "KDE Vinegret 5.x" aka KV5 to aggregate disparate libraries based on Qt5/KF5.

Vinegret is a mixed salad in Russian and Ukrainian cuisine and it includes a lot of different vegetables, in the same way like KV5 is designed to include very different libraries.

About current place of KDE Frameworks 5.x

Here is what we declare KDE Frameworks to be in every release accouncement [1]:
"KDE Frameworks are 60 addon libraries to Qt which provide a wide
variety of commonly needed functionality in mature, peer reviewed and
well tested libraries with friendly licensing terms."

Please note the words "commonly needed functionality". The libraries
grown up from kdepimlibs implement functionalities that does not
commonly needed, they are needed only for PIM-related applications.

Also note the word "addon" above. From my POV this means that KDE
Frameworks can be _added_ to Qt so that this whole Qt5&KF5 thing still
looks similar to Qt, but also has more modules. It is not saying that
KF5 is a "group of libraries based on Qt".

[1] https://www.kde.org/announcements/kde-frameworks-5.11.0.php

Marketing

KV5 is not meant to be attractive to normal users - nothing more than attractiveness of separate libraries. It only solves some of the pain in maintenaning and releasing libraries, so it is going to be attractive only for library maintainers and distro packagers.

Suggested policies for KDE Vinegret

License, coding style and base technologies used: same as for KF5 (LGPL2+/KDE, KDELibs coding style, Qt5/KF5 & partial C++11),
Release cycle: same as for KF5 (released once a month, but may not include some of the libraries - see entry 3 below; message freeze starts 2 weeks before a scheduled release.)
It *might* be best to release KV5 on a same day with KF5.
Releases are automated with scripts and done in the same way as for KF5 (always releasing from "master", each library has it own tarball.)
Maintainer of each library can decide whether to do a release or skip it for a given month.
Version number can be either automatically bumped or configurable manually in a text file.
Dependencies' version numbers are never bumped, even for dependencies on KF5.
SOVERSION is always taken care of by the library maintainer.
Tarball file names follow library version numbers, e.g. kimap-2.3.0.tar.xz.
ABI may not be broken without bumping SOVERSION (obviously.)
Use CMake namespace "KF5::" for KV5 libraries.
Dependency on any KF5 frameworks is permitted, including KF5::KDELibs4Support.

Version numbering

The KV5 releases should not necessarily have same version numbers as KF5, it can be for example "KDE Vinegret 5/2015-07". I think it's even better than "KDE Vinegret 5.12" because this way no one will expect it to contain kimap-5.12.0.tar.xz. So KV5 will be around only to simplify releasing of a huge number of libraries.

No library can bump its version number past the coming KF5 version. This is to always preserve a possibility to move any library from KV5 to KF5. This also means that when you bump SOVERSION, you can't bump the major version number because it should always be set to 5.

Module description in metadata.yaml

In the above I mentioned that releasing of each library should be optional and version numbers be configurable. Here is a possible approach to defining this in metadata.yaml (or a similar config in a library's Git repo):

If "versionMapping" is defined, then it is a dictionary that maps from KV5 release numbers to library version numbers, for example:
```
 versionMapping:
   5/2015-07: 2.2.1
   5/2015-08: none
   5/2015-09: 2.3.0
```
In this case the release scripts will bump the version in CMakeLists.txt to 2.2.1 for the July release and will tarball the library as kimap-2.2.1.tar.xz. KImap will not be included in the August release, there will be only a reference to the latest released version (kimap-2.2.1) in the release notes for KV5/2015-08. In September, the release scripts will bump the library version to 2.3.0 and create a new tarball again.
If "versionMapping" is not defined in metadata.yaml, then the library maintainer is happy with automated version bumping & releasing each month. Because "5/2015-08" is not a nice version number for a library, we should probably default to so predefined mapping like this:
```
 5/2015-07: 5.12.0
 5/2015-08: 5.13.0
 5/2015-09: 5.14.0
```

The approach with versionMapping requires less manpower than with a single "release: true/false" flag: if you know that your library will include new functionality in the next monthly release, you can bump from 2.3.0 to 2.4.0 in versionMapping and go on vacation for a whole month. You don't need to bump versions shortly before the release.

What happens when library goes unmaintained

If "versionMapping" is already present, but no one updates metadata.yaml on time and thus it misses information about the version number for a coming KV5 release, then this library will not be released (same as if there was a "5/2015-xx: none" line).

If "versionMapping" is not present in metadata.yaml, then the library will keep releasing every month without developers' intervention.

Targeted projects

A project (mainly libraries) may be interested in joining the KV5 release cycle because it does not fit KF5 for some of the following reasons:

It implements a niche functionality and is thus not worth marketing for mass audience with KF5.
Versioning in the scheme "major.minor.patch" is required. KF5 currently does not support different version numbers per framework.
Developers are afraid of having to break ABI earlier than Qt6 and KF6 are released, for example because of API change in a major dependency (e.g. when switching from gstreamer-0.10 to gstreamer-1.0) or because of a major change in web API of the web site the library is designed to work with.
The project is a plugin (or a pack of plugins), not a library/framework.
The code is not that quality and/or stable as KF5 requires.

What projects may join KV5:

Libraries that can potentially be used by different other projects.
Commonly used plugins accessed through KF5 frameworks (e.g. kio-extras, kross-interpreters) and by KV5 libraries (e.g. kipi-plugins - although I think Gilles Caulier would like to keep it part of digiKam SC).

What projects cannot join KV5:

Libraries designed for a specific application (e.g. libktorrent) or used only by applications contained in one product (e.g. libkmahjongg which is used only by games from the KDE Applications product.)
Plugins to be loaded by specific applications, e.g. kdeplasma-addons, extragear Amarok scripts (that are currently published on kde-apps.org.)
Stand-alone applications (should be released separately or as part of KDE Applications or KDE Plasma), e.g. digiKam, Kile, Amarok.

Current candidate subprojects

kimap and other libs extracted from kdepimlibs
kproperty, kreport and libs extracted from Calligra
libqapt
libqgit2
libs used mainly by the digiKam project:
- libkipi
- libkgeomap
- libkvkontakte
- libksane

Projects that already belong to other products

kio-extras (KDE Applications, since 15.08.0)
kross-interpreters (KDE Applications, since 15.08.0)

Maintaining the list of subprojects

Developer of a library needs to send an email to KV5 maintainer to request addition/removal of his project (or a Git branch in his project) to the list of subprojects of KV5. The list of subprojects may thus look like this:

foo[master]
bar[master]
bar[abi-v6]