[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: AppStream Metadata with our releases
From:       Julius_Künzel <jk.kdedev () smartlab ! uber ! space>
Date:       2024-03-23 20:06:46
Message-ID: 44ce4e7e-a31e-4e61-b60f-588ad4dcdadf () smartlab ! uber ! space
[Download RAW message or body]

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

> El divendres, 22 de mar=C3=A7 de 2024, a les 0:37:00 (CET), Julius K=C3=
=BCnzel 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 al=
l
>> 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 Gea=
r
>> 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 relea=
se
>> 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 releas=
e
>> 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'v=
e
> 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 p=
ast
> 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 the=
re
> forever?), so my suggestion is that we just add an release+url entry poin=
ting
> to
> =C2=A0 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 al=
ready
> 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 proble=
m to
> have.
>
> Cheers,
> =C2=A0 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/qualit=
y-g
>> uidelines/#release-notes [4]
>> https://invent.kde.org/sysadmin/appstream-metainfo-release-update/-/merg=
e_r
>> equests/6
>>
>> Julius K=C3=BCnzel
>> 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

[prev in list] [next in list] [prev in thread] [next in thread]