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 <aa...@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
signature.asc
Description: This is a digitally signed message part.
