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)).
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
