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

List:       kde-devel
Subject:    Re: AppStream Metadata with our releases
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2024-03-22 16:21:40
Message-ID: 1831151.OELxTCqBim () xps15
[Download RAW message or body]

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.

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.

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




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