Future frameworks releases

Wed Jun 17 07:17:09 UTC 2015

2015-06-16 12:54 GMT+03:00 Christian Mollekopf <chrigi_1 at fastmail.fm>:
> On Sun, Jun 14, 2015, at 07:53 PM, Alexander Potashev wrote:
>> 2015-06-11 21:20 GMT+03:00 Sebastian Kügler <sebas at kde.org>:
>> > Introducing exceptions increases the complexity of dealing with frameworks,
>> > their value really is in shared processes and requirements.
>> >
>> > I am strongly against watering it down. If some library is better off with its
>> > own versioning scheme and release process, then it simply should not be part
>> > of our Frameworks releases, but something else (which is entirely possible,
>> > still).
>>
>> Hi everyone,
>>
>> I totally agree that we should leave the KF5 policies alone.
>>
>> KImap and other libraries can easily be part of "something else" - a
>> new product to aggregate disparate libraries based on Qt5/KF5. I was
>> thinking of naming it "Lamedorks 5.x", but Albert will kill me for
>> such a name, so backing off to "KDE Vinegret 5.x" ;)
>>
>> Suggested policies for KDE Vinegret:
>>  1. License, coding style and base technologies used: same as for KF5
>> (LGPL2+/KDE, KDELibs coding style, Qt5/KF5 & partial C++11),
>>  2. 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.)
>>  2a. It might be best to release KV5 on a same day with KF5.
>>  3. Releases are automated with scripts and done in the same way as
>> for KF5 (always releasing from "master", each library has it own
>> tarball.)
>>  4. Maintainer of each library can decide whether to do a release or
>> skip it for a given month.
>>  5. Version number can be either automatically bumped or configurable
>> manually in a text file.
>>  6. Dependencies' version numbers are never bumped, even for
>> dependencies on KF5.
>>  7. SOVERSION is always taken care of by the library maintainer.
>>  8. Tarball file names follow library version numbers, e.g.
>>  kimap-2.3.0.tar.xz.
>>
>> 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.
>>
>> 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):
>>  (a). 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.
>>  (b). 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
>>
>> If "versionMapping" is already present, 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).
>>
>>
>> KV5 is not going to be a solution for one person or one use case,
>> because many other libraries were about to join KF5 while they don't
>> really need to in my opinion. For example the following libraries can
>> probably join the new product:
>>  - kimap and other libs extracted from kdepimlibs,
>>  - kproperty, kreport and libs extracted from Calligra,
>>  - libqapt,
>>  - libqgit2,
>>  - libkipi, libkgeomap, libkvkontakte and other libs used mainly by
>> the digiKam project.
>>
>>
>> The idea of a new product came to my mind before I actually started
>> spending hours reading these exhausting threads, and while reading I
>> did not see any major problems that this new product could not solve.
>> If you see any bottleneck with it, your comments are very welcome.
>
> This describes nicely what I think frameworks should become (I like the
> version bumping
> concept I discussed with David in the initial thread better, but details
> aside this is spot on).
> I think however it would be a bad idea to create a second set of
> libraries next to frameworks,
> because that would IMO defeat the purpose of frameworks. If frameworks
> is a collection
> of high quality kde/qt libraries, it shouldn't have a competitor that
> does essentially the same thing
> just without the versioning policy. This would create needless confusion
> about where
> to put or find libraries, and reduce the attractivity of both
> propositions.

Hi Christian,

1. (Sorry, I need to write to let you know what I think KF5 should be;
feel free to skip to section 2.)

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".

2. I think changing the KF5 conventions midway its release flow is
wrong. This is not what a mature product should do. So to keep KF5
attractive, we should preserve its rules as much as possible.

Remember Linux kernel changing its version number scheme from 2.6.x to
3.x. This simple change broke a lot a legacy code. I don't want anyone
to get the same kind of pain from where they did not expect it -
stable and mature KF5.

3. You say about confusion about where to put or find libraries. I'll
tell you, almost no one needs to know what product a library/framework
comes from (KF5 or KV5.) We can keep the KF5:: CMake namespace for KV5
libraries

4. The approach with versionMapping requires less manpower: 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.

5. 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.

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

-- 
Alexander Potashev