On Saturday 17 October 2015 17:53:25 Alexander Potashev wrote:
> Hi David,
>
> 2015-09-28 23:21 GMT+03:00 David Faure <fa...@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, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
