Re: AppStream Metadata with our releases
On Montag, 25. März 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 : > > > El divendres, 22 de març de 2024, a les 0:37:00 (CET), Julius Künzel va > > > escriure: > > >> - Also it would be convenient to add noteworthy changes to the metadata > > >> together with the related code change. However at the moment for KDE > > >> Gear > > >> the release is usually only added to the metadata a few days before > > >> tagging. Would it be possible to add the next minor release to the > > >> release > > >> branch right after the current one has been released and the next major > > >> release to master ones the upcoming version has been branched? > > >> > > >> I belive this makes it easier for developers to contribute to the > > >> release > > >> meta info and I hope it hence raises motivation to do so. > > > > > > My pessimistic opinion is that no one is going to add release notes, > > > we've > > > tried multiple ways to do it, even just asking people to add a keyword > > > to > > > the commit log if that commit log was release news worthy and no one did > > > it past the first few weeks/months. > > > > Well, that might happen, but we don't know if we don't try... And as I > > don't see this causing any extra work and (yet) can't see any downsides, > > it is even worth it if it helps just a single app or developer, no? > > 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 It's not only apps.kde.org. The release (notes) information is also used by the scripts preparing meta data for publication in various app stores. The Microsoft Store script uses the description of the most recent release found in the AppStream data for the What's New section. OTOH, the script uses the JSONified AppStream data published by apps.kde.org, so that omitting future releases in the JSONified AppStream data would also work for Microsoft Store publications. I'm not sure how the other stores use the release notes. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: AppStream Metadata with our releases
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 : ... 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
Re: AppStream Metadata with our releases
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 : ... > > > > 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.
Re: AppStream Metadata with our releases
On Wed, Mar 27, 2024 at 5:40 AM Volker Krause wrote: > 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 : ... > > > > > > 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? > Please see https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline I imagine he uses https://docs.gitlab.com/ee/api/pipelines.html#get-the-latest-pipeline to fetch the outcome of that. Note that the above API is not suitable for building a public dashboard due to the number of queries we would need, but it is fine for one off runs like what Albert does. > > Regards, > Volker Cheers, Ben
Re: AppStream Metadata with our releases
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 : ... > > > > > > 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
