2015-06-11 21:20 GMT+03:00 Sebastian Kügler <se...@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 _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team