backwards compatibility & how namespacing might help or not

[Harald Sitter]

On Mon, Jan 26, 2015 at 10:01 PM, Albert Astals Cid <aacid at kde.org> wrote:
> Yeah, i don't think that what you suggest really helps much, otherwise you'd
> end up with two kglobalaccels running at the same time, which is probably a
> very bad thing.

It's dbus invoked, so in the kglobaccel case specifically david
edmundson suggested that correct naming of the service file in
frameworks would make sure that it is the file used by dbus-daemon to
run the service.
A potentially more interesting problem would be KIO slaves moving
about, as I don't think there is any provisioning for two slaves
providing the same protocol and having one outrank the other.

> So yes, a better way of moving thing arounds is needed, or maybe we just need
> the dust to settle a bit so that we realize where each thing really belongs
> and it'll hopefully fix itself?

Waiting for the dust to settle is what I have been told for almost a
year now. How much more dust can there possibly be? :P
The problem IMO is that supposedly the existing things will settle at
some point, that doesn't mean a new thing couldn't end up in some
plasma repo for 5.7 and then be moved into a framework 5.130 because
it suddenly fits better into frameworks.

As a community we should at the very least decide whether or not
frameworks ought to be runtime compatible with non-frameworks bits
(such as plasma) and follow through with that.
If we don't want to have this level of compatibility then it's fine as
well, it just needs to be made clear I feel.

As of right now I don't think anyone ever told me that runtime bits
aren't supposed to be compatible when I highlighted a conflict because
of things moving about. It always was a lot of handwaving and
explaining that things are still changing. And to be quite honest, if
things are changing such that I can not upgrade my frameworks without
having to recompile or upgrade something unrelated as well, that feels
a lot like a BIC.

HS