You are correct - sorry. I’ll change my vote to +0 then (i.e. “that’s not the way to do it, sorry”). I did miss the fact that cross-publisher autoconnects are not usual and that it depends heavily on the provider guaranteeing a stable “interface”.
@jdstrand, Note that these people are not using the kde-frameworks-5-core18 snap directly, but this simply gets pulled in because they use the kde-neon extension. This adds to their confusion and frustration.
Although I agree with @damir that this situation is very confusing, I have tried to warn publishers from using the kde-neon extension by putting the following notice on top of the kde-neon extension documentation:
This extension is currently only available for the KDE project itself. Snaps from non-KDE publishers will not get automatically connected to the KDE runtime snap required by this extension.
I understand and respect the decision to only auto-connect content snaps when the author of the content snap agrees to that. Otherwise, we would end up with a bunch of snaps suddenly breaking because a content snap breaks binary compatibility.
However, I think this issue could have been handled better by the Snapcraft team. It is very confusing for publishers that an official Snapcraft extension can only be used by a single publisher, especially since the gnome extension is intended to be used by everyone. I asked about the plans for the Gnome and Neon extensions back in Oktober and nobody raised the issue that the Neon extension was only going to work for the KDE Neon project. So I wrote documentation on how to use the Neon extension, which was even mentioned in an Ubuntu blogpost, but even the Ubuntu blogpost did not have a clear warning that this extension would not work for snaps published by other people.
So I was very surprised that when I contacted the Snapcraft developers about the content snap not being auto-connected, they told me that this was not a mistake, that this was deliberate…
So, to summarise, which is the correct or “preferred” way to build a qt snap?
Add the kde snap in stage-snaps?
Use the version of qt in bionic via the desktop-qt5 part?
EDIT:
There is also the kde guide: https://community.kde.org/Guidelines_and_HOWTOs/Snap
that basically shows something very similar to the kde-neon extension, just not automated
This is my own opinion:
Currently, I think you get the best end-user experience by using the desktop-qt5 part. This is a tutorial for how to do that: [Deprecated] Desktop App support - Qt5. If you’re targetting default Ubuntu, this option also has the best desktop integration; it changes the KDE theme to look like the Gnome theme.
After kde-frameworks-5-core18 has a global auto-connection, the KDE-neon extension will be a comparable option with some advantages and some drawbacks. This is a tutorial for the extension: The kde-neon extension
Advantages of kde-neon extension
Disadvantages of kde-neon extension
The content snap from the KDE guide will not work for the same reason as the kde-neon extension. Imo, that guide is inferior to the kde-neon extension in every way; the extension basically does everything the guide tells you to do, but the extension does it better.
@sergiusens and @cjp256 - while it sounds like the kde publisher is going to request a global auto-connection for the kde frameworks content snaps, assuming that is voted in the affirmative, are there other official extensions that are only used by a single publisher? If so, can something be done to make this a better developer experience?
Well, the publisher is going to request auto-connection… it was planned about a month ago, maybe just delayed to all the things going bonkers in the world we live in 
Connecting interfaces between snaps of different publishers should however be an agreement between publishers, I believe this is what we agreed to so many moons ago. So what is the constraint or problem if the publisher is willing to commit stability for the snap of a different publisher but not want to for all publishers?
This is hypothetical as I noted that this publisher in particular was seeking auto-connect for this particular snap.
In this hypothetical case where the provider isn’t pursuing a global auto-connect, this is fine so long as both sides agree in the forum it is ok. The snap declaration would then be in the consuming snap to allow auto-connect to the providing snap.
Any news on the auto-connect for kde-frameworks-5-core18? There seems to be not much going on in the related tickets.
I’m guessing everyone is waiting for a reaction from @jriddell. It wouldn’t hurt to give him a reminder on Matrix? He hangs out in the KDE Neon channel: https://webchat.kde.org/#/room/#kde-neon:kde.org
This is no longer needed now that global auto-connect has been granted: Allow Global auto connect for kde-frameworks-5-core18
Great news, it’s working, thanks!
