Thank you for making this request.
@reviewers - while kde-frameworks-5-qt-5-14-core18 does not follow our current guidelines for naming, which is typically <thing>-<version>-<ABI-hint>, I don’t think that is a problem. To date, this has not been an issue since the KDE team is free to name their private content anything they want.
The snapcraft.yaml does use this for the content attributes in its slot declarations:
content: kde-frameworks-5-68-qt-5-14-core18content: kde-frameworks-5-qt-5-14-core18-all
If creating the snap anew today before it had any consumers, we might instead recommend ‘s/core18/1804/’ for consistency with other globally connected content snaps, but I don’t recommend this here because a) ‘core18’ reflects the base snap in use, b) this conveys “Ubuntu 18.04” at least as well as the alternative and c) there is a lot of developer and snap momentum with the existing naming.
Put simply, the name of the snap and the value of the “content” attribute in the two slots of the snap are conveying everything we require IMO.
@jriddell - rebuilds of this snap would be fine so long as they don’t break ABI, remove files, etc (ie, do anything that might break a 3rd party consumer). By your statement, I think the answer to this next question is implied, but I need to ask this explicitly: can you or someone authoritative as the KDE publisher comment on the stability of the libraries, APIs, ABIs, etc of this snap and provide any additional information related to the promise of updates to this snap not breaking 3rd party publishers?
@jriddell - you mentioned creating a new snap using core20, will this use something like the following in its snapcraft.yaml (name, base and content attribute are the key points where ‘X’, ‘Y’, ‘Z’ and ‘N’ are at your discretion):
name: kde-frameworks-X-qt-Y-Z-core20
base: core20
slots:
kde-frameworks-X-N-qt-Y-Z-core20:
content: kde-frameworks-X-N-qt-Y-Z-core20
interface: content
...
?
Thanks!