Naming scheme for Qt5/KF5-based libraries outside of KF5

[Boudhayan Gupta]

On 27 September 2015 at 04:09, Albert Astals Cid <aacid at kde.org> wrote:
> El Diumenge, 27 de setembre de 2015, a les 04:01:26, Boudhayan Gupta va
> escriure:
>> On 27 September 2015 at 03:36, Albert Astals Cid <aacid at kde.org> wrote:
>> > El Dissabte, 26 de setembre de 2015, a les 16:27:22, Sune Vuorela va
> escriure:
>> >> On 2015-09-26, Alexander Potashev <aspotashev at gmail.com> wrote:
>> >> > 1. Many people prefer a "KF5" prefix, e.g. libKF5Screen.so).
>> >> > 2. Another way of naming is a -qt5 suffix, e.g. libmarblewidget-qt5.so.
>> >> > 3. (probably some others?)
>> >> >
>> >> > Friedrikh said in [1] that using a KF5 prefix for all libraries will
>> >> > "blur the hint by the name if something is part of KF5 or not".
>> >> >
>> >> > Any thoughts? I believe we can have guidelines for library names.
>> >>
>> >> I do think that having things named KF5 that aren't actual frameworks is
>> >> bad for several reasons.
>> >>
>> >> 1) It blurs what's a framework
>> >> 2) We promise ABI and API compatibility for frameworks, but not for
>> >> other things
>> >> 3) Moving something from "not a KDE Framework" to "KDE Framework" gives
>> >> a last chance for fixing up abi/api.
>> >>
>> >> so. foo-qt5 is fine for a qt5 version of foo.
>> >
>> > I agree, the problem is that there's few exceptions to copy from, so
>> > that's
>> > the exact reason libkdegames has that KF5 thing in the name, the guy that
>> > did the port just copied what the frmeworks do.
>> >
>> > So anyone up for write what "a library that is not frameworks should do to
>> > be nice in the KDE land"?
>>
>> We could kill two birds with one stone here, creating a new KDE module
>> just for libraries (say, KDE Companion Libraries or something) and put
>> everything in the KC5 (or whatever we decide) namespace.
>>
>> I'm all for just putting everything in KDE Support, using the KS5
>> namespace and removing the tier0 restriction from Support.
>
> I don't see which birds it kills, as far as I see it it only gives you the
> problem of having yet another product to release.

Release it with the Applications release-unit, since the users of the
libraries are applications.

-- Boudhayan