Future frameworks releases

[Christian Mollekopf]

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.

Cheers,
Christian