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

[Boudhayan Gupta]

Hi Friedrich,

On 27 September 2015 at 20:55, Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
> Some bummer here:
> a) not all libraries are in repositories of their own
> b) not all libraries are released on the same cycle
>
> E.g. a) happens because the libs could be shared libs for sharing between
> multiple executables/plugins developed in a single repo. Or they are only
> slowly established as shared code and still developed strongly coupled with
> their main user executable/plugin and for that live in the same repo.
> And b) is because there are a few libs in extragear or playground repos, so
> not covered by the "KDE Applications" release cycle or forced to follow.

So let's clean this mess up.

For applications, Extragear seems to be the place to live in if you
manage your own release cycles. I see no reason libraries should also
be treated the same way.

What I propose is that all libraries which want to manage their own
release cycles and their own namespaces, be moved to Extragear Libs
and release from there. All the libraries which can stick to the
Applications release-unit, move to Support or a new module and be
released with them.

This has the advantage of Application libs not having to maintain
API/ABI stability, since the Applications from one release will depend
on the libs from the same release. Extragear Libs devs, who want to
manage their own cycles etc, will however have to make API/ABI
guarantees.

Also, I get the feeling that Extragear is treated as a second-class
citizen. It doesn't have to be. Apps and libs in Extragear should be
held to the same standards as the rest of the KDE modules. The only
difference ever should be the release cycles.

> So while I agree that having all libs nicely separated would be good to have,
> if only for discoverability, doing that with a single module at least
> currently would not work.

Can you elaborate on why a single module would not work?

> ((Long-term we should perhaps look into that, because right now the layout of
> our repository structure does not make a difference between repos with
> executables, plugins and libraries (and mixed ones).
> And IMHO if we have libs, thus code intended to be shared between other
> software, it would be great if it would be easy to developers to simply browse
> all of the libs to find something perhaps matching. If that list would be a
> virtual one, fine as well, but having the real repositories ordering also
> follow that grouping helps shaping minds and reduces complexicity needed due
> to the mapping.
> (Would also make it simpler to know which libs there are that should be also
> noted at inqlude.org)

+1

Side note here - I'm very interested in getting Vlc-Qt under the KDE
umbrella, if the maintainers of Vlc-Qt and KDE are in support. A
dedicated library module would be a great place for it.

> But different topic, with quite some details and strings attached, worth at
> least a different thread (and someone who can and would drive any planning for
> that for some time, not me).))

I'd love to help. I love organization ;-)

Cheers,
Boudhayan.