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

[David Faure]

On Saturday 17 October 2015 17:53:25 Alexander Potashev wrote:
> Hi David,
> 
> 2015-09-28 23:21 GMT+03:00 David Faure <faure at kde.org>:
> > Naming: "experimental" sounds like "it will be a framework at some point, when it
> > stabilizes". Maybe we should say "internal" instead [was: 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.
> 
> Sounds good, I'm only worried about users/developers disregarding
> these libraries because they have "experimental" in their names, even
> though they may have been around and work OK for 5+ years already.

Wait, if they have been around and work OK for 5+ years, isn't it time to stabilize
and guarantee API and ABI?

The whole point of "experimental" is to convey the message that the API isn't stable
yet, so yes, the point *is* that developers should disregard such libraries if they
need a stable API and ABI.

If the point isn't that it will stabilize at some point (and become a real framework)
then you want "internal" instead, as I said in the quoted text above.

> We still need some distinct naming scheme/namespace for kf5-experimental, right?

Actually I don't think so. "experimental" becomes stable at some point, and at that
point we don't want to have to port all users of the code.

On the other hand, "internal" probably stays "internal" for ever, so for these it would
make sense to have that in the library name maybe? Or just no KF5 in the name.

Let me expand my summary a little bit, because I'm not sure which type of lib you're
asking about exactly.

I see 7 types of libs:
* public, separate   (qca, poppler, libkolab, etc.) (external, or at least separately released; no KF5 in the name)
* public, part of KF5  (that's KF5 as you know it; API/ABI is guaranteed)
* public but "experimental", released with KF5 (i.e. a framework that will stabilize and become part of the above)
       These mean "you can start using them now but ABI will break, or you can wait and you'll get stable ABI".
       kdelibs/kactivities was experimental like that AFAIK.
* internal, part of KF5 (i.e. a lib meant to be used by apps and workspace, but not outside of that)
       To the outside world this says "do not use, ever" (or convince us to make it KF5 proper).
* apps-internal (e.g. libkdegames; no KF5 in the name; cannot use in worskpace)
* workspace-internal (e.g. libksysguard; no KF5 in the name; cannot use in apps)
* private to one app (e.g. libkonqueror_private, that's just for unittests)

Again, note that SIC are not possible anyway, for experimental or internal-in-KF5 libraries.
So e.g. one can add virtual methods (and bump the so version), but not remove/rename anything,
because of the separate release schedule for frameworks, apps and workspace. So is this
really worth the separate categorization? If libs that are meant to be shared between
apps and workspace need stable API anyway then they might as well become proper
KF5 libs, being able to make BICs but not SICs is only a tiny gain IMHO.
I suppose version-number-ifdefs in apps allow to make a few SICs too, but this is
not trivial to do right (when apps code is already released and must keep compiling).

Before going further about naming, please tell me which type of lib you're thinking about,
and consider whether there is that much to be gained by using the "experimental" or "internal"
concept for it.

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