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 <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?
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