AppStream Metadata with our releases

[Heiko Becker]

On Monday, 25 March 2024 23:23:01 CET, Albert Astals Cid wrote:
> El dissabte, 23 de març de 2024, a les 21:06:46 (CET), Julius Künzel va 
> escriure:
>> 22.03.2024 17:22:33 Albert Astals Cid <aacid at kde.org>: ...
>
> It is some extra work (not a lot, but some).
>
> You're asking for the workflow of creating to be releases to be changed by 
> creating the entry in the file earlier, that alone is a bit of work, but it 
> has several other consequences:
>
>  * https://apps.kde.org/okular/ shows releases from the appstream file (i 
> think) meaning that the code should learn to ignore releases in the future. 
> Arguably we would need also now, but given the data is added 
> just a few days 
> before the actual release i think users can understand "this release will 
> happen soon)" compared to a thing one month in the future
>
>  * What happens if we have to change the release date or release version 
> number (hasn't happened in a good while, but wouldn't be a bad thing to 
> prepare for it). We would need to update the string or date of an existing 
> entry, as far as I know we don't have tooling for that (because we only add 
> the data to the file when we're almost sure abiyt it).

In addition I'm a litte bit wary of conflicts when cherry-picking the 
appstream changes between branches, which the script does after 
incrementing the version. I saw at least conflicts in itinerary's releases 
notes and e.g. kdeconnect's or okular's windows releases in the past, which 
isn't that much of a problem but it could become one with the 245 modules 
of gear (to be fair not all have appstream metadata (yet)).

Otherwise I'd just miss the opportunity to trigger a CI build for 
everything again shortly before the release, but I'd guess that's easy to 
get over.

Regards,
Heiko