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

[David Faure]

On Monday 28 September 2015 01:43:59 Alexander Potashev wrote:
> And you can also look at the numbers: KF5 grows at the rate of less
> than one framework per month. We probably don't have enough manpower
> to review dozens/hundreds of libraries in a short period of time.

So you would rather aim for releasing crap ASAP than for quality? ;)

On Sunday 27 September 2015 04:01:26 Boudhayan Gupta wrote:
> We could kill two birds with one stone here, creating a new KDE module
> just for libraries (say, KDE Companion Libraries or something)

It seems to me that you're reinventing KF5.

Either a lib is meant to be used by both apps and workspace (and possibly
external apps) (see below for details),

Or a lib is only meant to share code between apps (e.g. libkdegames) and it
should be released as part of the apps. We can invent a new prefix or suffix for
these (K5A?) but the main thing is that there is no need for a new product,
for libs that are only used by the Applications product.


If a lib is to be used by both apps and workspace, then I see two cases
1)  the lib has stable API/ABI, then it's easy (name it -qt5 if you release
it separately, like e.g. QCA, or make it a framework and it'll be released
automatically)

2) the lib cannot promise ABI stability yet. In that case we can introduce another
type of framework, let's say experimental to reuse an old kdelibs concept.
[I suggested something like that in the "Baloo Framework - License Exception"
thread 8 months ago, but that was not a solution back then (the license problem
was too big). It would be one here, though, IMHO.]

In practice my suggestion is:
* just like we have "portingAids: true" in framework YAML files, we can have
"experimental: true".
* the tarballs for experimental frameworks go into a separate subdir (just like portingAids)
* there would be no api docs on api.kde.org for these frameworks (otherwise
external application developers would think they promise BIC just like proper KF5 does)
* the .so number still has to go up every month where a BIC happens (that's the rule)
* SIC should not happen. Since KF5, apps and workspace are not released together,
a SIC would mean that upgrading one would break the other. One would have
to make sure to keep deprecated stuff around, and to preserve behaviour.
This is the price to pay for sharing between apps and workspace.

Naming: "experimental" sounds like "it will be a framework at some point, when it
stabilizes". Maybe we should say "internal" either, i.e. used internally by apps
and workspace, don't use outside of that. Which still doesn't prevent a framework
tagged "internal" from turning a proper public framework later.

Maybe the "experimental" or "internal" should even be part of the tarball name
and distro package names, to make really sure app developers see that.

Again, none of this is needed for libs that are only for apps, or only for workspace.

In summary, I see 6 types of libs:
* public, separate   (qca, poppler, libkolab, etc.) (external, or at least separately released)
* public, part of KF5  (that's KF5 as you know it)
* internal, part of KF5 (doesn't exist yet, but I'm open to the idea, see above)
* internal, part of apps (e.g. libkdegames)
* internal, part of workspace (e.g. libksysguard)
* private to one app (e.g. libkonqueror_private, that's just for unittests)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5