AppStream Metadata with our releases

[Volker Krause]

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?

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240326/e4fde4af/attachment.sig>