Future frameworks releases

[Alexander Potashev]

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.

-- 
Alexander Potashev