AppStream Metadata with our releases

[Albert Astals Cid]

El dimarts, 26 de març de 2024, a les 17:39:25 (CET), Volker Krause va 
escriure:
> On Dienstag, 26. März 2024 08:59:29 CET Heiko Becker wrote:
> > 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)).
> 
> Sorry about that! I try to keep both branches in sync usually, if there is
> anything I can do/do differently to not impact your work I'm happy to do
> that of course.
> 
> > 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.
> 
> Albert seems to have an alternative way using API (?) for the weekly build
> status reports, I guess that could be reused/combined somehow?


It's just some lines of python that interact with the gitlab api, they are not 
very polished, but i can put them on a random repo if you want to have a look 
at them.

Cheers,
  Albert

> 
> Regards,
> Volker