Appstream files can take a release date and Discover now shows this to the user. Make releaseme update the releasedate to the appstream file before it makes the tar.
In this case, it also needs to add the version. See https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-releases <description> tags are optional and open a can of worms, so let's not consider that here.
*** Bug 390195 has been marked as a duplicate of this bug. ***
I feel like I discussed this somewhere already? Bunch of problems: a) how to find appdata files? in general we can search *appdata.xml BUT what if the source configures the file through cmake? (I do remember at least 3 repos where I have seen that) b) what's the date? date of tar creation? date of tag? date of actual public release? c) tarme should be readonly on the repo as it does, or at least did, get used by some distros to generate snapshot tarballs (FTR: doesn't affect neon since neon doesn't go through tarme) The largest problem to me is that KDE does releases in such a messy way. Where any amount of time may pass between the release process beginning and it actually getting announced to the public. In practice the release git tag should present the state of the source as it is in-tar. For that to be true, releaseme would have to inject the release data into the appstream file before creating the tar. Essentially before the current functionality of tarme runs. The trouble is that N days may pass between that time (which is where the data would get generated) and running tagme, so the date that was injected may be wrong. And then there is also the design problem that tarme should not be pushing to the repo. That could conceivably be solved by having a separate command to inject the release metadata (IOW one runs appdatame -> tarme -> tagme). I am not convinced that is all to nice but meh.
a) searching for appdata.xml seems good enough for me b) configurable at time of running but default to today for lack of anything better c) hmm, I guess a new command is wanted then
I am not sure that particularly fits within the feature scope then. It'd be like 20 lines of code entirely detached from everything releaseme. Not that I am saying that script couldn't be within releaseme, but to me this feels a lot more like a script you would run whenever. Similarly to how version bumps are not in releaseme really.
Yeah if you search for *appdata.xml, you won't get *appdata.xml.in, which would be the pre-cmake-configured version. Date = date of running the script seems reasonable to me, since this will generally be run on the date of release, right?
Just the version attribute is needed to pass $ appstream-util validate-relax (this is what Flathub requires) So mabye using cmake's configure_file is enough.
Also remember: Release dates can't be in the future, or they won't pass appstream-util validate-relax! This conflict with how git tags / cmake VERSION variables / tarball creation is handled in KDE.
If comment #8 is true, then this bug is a WONTFIX. Tars are created before the release date.
Discussion on this is at https://phabricator.kde.org/T10755 and at https://phabricator.kde.org/T10812
Closing pending discussion on phabricator how this should even work.