Thank you for making this request.
@reviewers - like with kde-frameworks-5-qt-5-14-core18, while kde-frameworks-5-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-67-qt-5-14-core18content: kde-frameworks-5-core18-all
For the same reasons as the kde-frameworks-5-qt-5-14-core18 snap, 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 - I noticed that the names of the kde-frameworks-5-qt-5-14-core18 and kde-frameworks-5-qt-5-14-core18 snaps and the content attributes of the “-all” slot in this snap and the kde-frameworks-5-qt-5-14-core18 are not consistent with each other.
Eg, where kde-frameworks-5-qt-5-14-core18 has:
-
content: kde-frameworks-5-68-qt-5-14-core18(fine) -
content: kde-frameworks-5-qt-5-14-core18-all(inconsistent)
kde-frameworks-5-core18 has:
-
content: kde-frameworks-5-67-qt-5-14-core18(fine) -
content: kde-frameworks-5-core18-all(inconsistent)
Why does kde-frameworks-5-qt-5-14-core18 include ‘qt-5-14’ in its name and ‘-all’ slot, but kde-frameworks-5-core18 does not? Should kde-frameworks-5-core18 include ‘neon’ somewhere in the name?
@jriddell - 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?
Finally, @jriddell - do you plan to create other coreX variations of this snap? If so, will the updates follow a format as described in my last question of comment 4 from the kde-frameworks-5-qt-5-14-core18 request?
Thanks!