2016-04-22 12:45 GMT+02:00 Harald Sitter <sit...@kde.org>: > Lost mailing list CC, I am assuming that was intentional? (:
Oops, no - I didn't see the CC and didn't hit reply-all then... Adding the list back (hope your reply isn't private ;-) ), the mail I sent first is below. > On Thu, Apr 21, 2016 at 4:21 PM, Matthias Klumpp <matth...@tenstral.net> > wrote: >> 2016-04-21 12:26 GMT+02:00 Harald Sitter <sit...@kde.org>: >>> ahoy ahoy! >>> >>> http://commits.kde.org/extra-cmake-modules/4b7a90bfe7a3e2eb3ae83c946c182a79fabc51e3 >>> >>> doesn't that break compatibility with older appstreams for everything >>> that uses ECM? if so, I am not sure that is appropriate TBH >> >> It shouldn't, since all tools which handle this have been adapted >> already - I expect this to be only enabled for the next generation of >> KDE apps, so this change shouldn't hit distributions right now (I hope >> I got e-c-m's release schedule right here...). > > ECM gets released monthly, so this would hit anyone that wishes to > push the new ECM onto an existing stack that has an older appstream. Hmm, that could indeed be a problem. The main component which should not be out of date is the server-side module which generates the distro metadata. AFAIK all distros are up-to-date on that, but we could also wait a few more months to be sure everyone has updated. The client tools not being updated shouldn't be a big issue, they rarely read /usr/share/appdata or /usr/share/metainfo. > And technically we expect distributions to do that which is why we > technically aren't breaking backwards compat. Hehe, does Debian know that? ;-) > Now if you were to say > that the appstream tools already looked in /metainfo as well as > /appdata for a year or two True for AppStream itself (~6months), but the GNOME world switched only recently. > but we are simply late to the party, then I > guess the change might be done just as well even if technically > breaking compat. > > Whether or not we are aware of an ECM user that would have a problem > with this or not doesn't really factor into it though, just like we > don't break ABI because we think that no one is using a specific > interface. Okay, that's an entirely different thing then - so, when are we allowed to do such breaking changes? Moving away from appdata/ is something I care much about, because as the recent discussion at KDE has shown, people still seem to think this metadata is only for applications (which it isn't). I think to not break assumptions, reverting that commit is fine now, but knowing some time when changing it is okay would also be good. Generally, the critical factor is distributions upgrading their AppStream generator, which happened at Debian and Ubuntu, should be done at Fedora (I need to ask again). I have no data on OpenSUSE and Arch yet, but I can ask them too. Cheers, Matthias 2016-04-21 12:26 GMT+02:00 Harald Sitter <sit...@kde.org>: > ahoy ahoy! > > http://commits.kde.org/extra-cmake-modules/4b7a90bfe7a3e2eb3ae83c946c182a79fabc51e3 > > doesn't that break compatibility with older appstreams for everything > that uses ECM? if so, I am not sure that is appropriate TBH It shouldn't, since all tools which handle this have been adapted already - I expect this to be only enabled for the next generation of KDE apps, so this change shouldn't hit distributions right now (I hope I got e-c-m's release schedule right here...). This might be an issue with backports on Fedora, but that would be the only problem I am aware of. Ubuntu/Debian are fine, and AppStream, libappstream-qt, libappstream, appstream-glib appstream-builder and appstream-generator are all adapted for this change. So it should be safe ^^ Honestly, I am very eager to get rid of the old misleading name too - if you notice anything that breaks, please let me know and we can revert that change. (One thing required in particular would be updating the validator at the CI system (which would only validate the new path then, though)) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/ _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
