AppStream Metadata with our releases

Julius Künzel jk.kdedev at smartlab.uber.space
Sat Mar 23 20:06:46 GMT 2024


22.03.2024 17:22:33 Albert Astals Cid <aacid at kde.org>:

> El divendres, 22 de març de 2024, a les 0:37:00 (CET), Julius Künzel va
> escriure:
>> Hi!
>>
>> (This mail goes to multiple lists, please reply to kde-devel)
>>
>> With Flathub beeing more strict on its AppStream metadata guidlines [1]
>> there is yet another spotlight on AppStream metadata.
>>
>> AppStream metadata are consumed by app stores like Flathub, Snapcraft,
>> Discover, our scripts to submit apps to the Microsoft Store and last but
>> not least by apps.kde.org [2].
>>
>> For release info in particular the quality guidelines say: "Make sure all
>> your releases have release notes, even minor ones." [3] As I think this
>> makes perfectly sense, I like to propose two things that seem straight
>> forward to me:
>>
>> - We should not remove older releases from the AppStream data as already
>> suggested by Carl in a merge request [4].
>>
>> - Also it would be convenient to add noteworthy changes to the metadata
>> together with the related code change. However at the moment for KDE Gear
>> the release is usually only added to the metadata a few days before
>> tagging. Would it be possible to add the next minor release to the release
>> branch right after the current one has been released and the next major
>> release to master ones the upcoming version has been branched?
>>
>> I belive this makes it easier for developers to contribute to the release
>> meta info and I hope it hence raises motivation to do so.
>
>
> My pessimistic opinion is that no one is going to add release notes, we've
> tried multiple ways to do it, even just asking people to add a keyword to the
> commit log if that commit log was release news worthy and no one did it past
> the first few weeks/months.

Well, that might happen, but we don't know if we don't try... And as I don't see this causing any extra work and (yet) can't see any downsides, it is even worth it if it helps just a single app or developer, no?

>
> It seems appstream has finally added the <url/> support (or maybe was there
> forever?), so my suggestion is that we just add an release+url entry pointing
> to
>   https://kde.org/announcements/gear/x.y.z/
>
> This way we don't have to do the work twice and has the added bonus of already
> translatable.
>

This is a nice suggestion too!
However, I don't think this conflicts with my suggestion as the text in the appstream should usually be just a short summary of the highlights. So let's do both?

> Only "problem" is that maybe if we get too many people contributing their
> release news the announcements gets too long, but that'd be a nice problem to
> have.
>
> Cheers,
>   Albert
>
>
>>
>> I am happy to hear your opionions, thoughts and concerns!
>>
>> Cheers,
>> Julius
>>
>> [1] https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines
>> [2] https://apps.kde.org/
>> [3]
>> https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/quality-g
>> uidelines/#release-notes [4]
>> https://invent.kde.org/sysadmin/appstream-metainfo-release-update/-/merge_r
>> equests/6
>>
>> Julius Künzel
>> Volunteer KDE Developer, mainly hacking Kdenlive
>> KDE GitLab: www.invent.kde.org/jlskuz https://invent.kde.org/jlskuz
>> Matrix: @jlskuz:kde.org https://go.kde.org/matrix/#/@jlskuz:kde.org



More information about the kde-devel mailing list