[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: AppStream Metadata with our releases
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2024-03-25 22:27:22
Message-ID: 3164542.EvI8D1j4F7 () xps15
[Download RAW message or body]

El dilluns, 25 de març de 2024, a les 19:37:07 (CET), Volker Krause va 
escriure:
> On Freitag, 22. März 2024 00:37:00 CET Julius Künzel wrote:
> > AppStream metadata are consumed by app stores like Flathub, Snapcraft,
> > Discover, our scripts to submit apps to the Microsoft Store and last but
> > not least by apps.kde.org [2].
> 
> Same for generating the package metadata on Android, both for our F-Droid
> repositories and the Google Play store.
> 
> > - 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?
> 
> At least in the past the appstream validator complained about releases dated
> (too far) into the future, but that doesn't seem to be a problem anymore
> fortunately.
> 
> As Itinerary was mentioned, the process there currently is to run David's KF
> changelog script over all repositories in Itinerary's dependency chain and
> take the top 5 or so most visible/important changes (which here are
> actually often from other repositories). The commit adding the release to
> appstream is my reminder for that currently, but there's other ways to do
> that, so for Itinerary the proposed change wouldn't make much of a
> difference either way.

This brings an interesting point, it would seem that the right time to add the 
release description is at the end of the release cycle when you know all the 
changes, not when a particular commit is made.

Because if there's 400 changes, you will only want to have the 5 more 
important changes in the description, but if there's only 5 changes, you may 
as well add them all.

Cheers,
  Albert

> 
> Regards,
> Volker




[prev in list] [next in list] [prev in thread] [next in thread]