Currently, we have the need to add references to release artifacts to releases, both for firmware as well as for Flatpaks and other bundled application which need to make the source code location they were building from known for the current release.

Traditionally, we had the location tag for that, which was only ever used by firmware type components and was accompanied by the checksum tags to denote the release checksums for the given release artifact.
When having source tarballs in there as well and potentially more and different release artifacts, the current approach will not work anymore.
(Ab)using the <url/> tag for this purpose is not a good idea, as the url tag points to human-readable webpages in its current context, and not to immediately downloadable artifacts. We also can not easily add checksums to this tag.

So, I propose the artifacts tag as child of the <release/> tag. This mechanism will displace the current location and checksum tags as briefly described in https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Firmware.html#tag-firmware-releases (of course with a very, very long backwards compatibility phase).

This is the proposed layout:

<artifacts>
  <artifact type="binary" platform="x86_64-linux-gnu">
    <location>https://example.com/mytarball.bin.tar.xz</location>
    <checksum type="sha256">....</checksum>
    <checksum type="blake2">....</checksum>
  </artifact>
  <artifact type="binary" platform="win32">
    <location>https://example.com/mytarball.bin.exe</location>
  </artifact>
  <artifact type="source">
    <location>https://example.com/mytarball.tar.xz</location>
    <checksum type="sha256">....</checksum>
  </artifact>
</artifacts>

Constrains:

• An artifact must have a location child
• An artifact must have a type (source or binary are allowed)
• The platform property is optional
• Artifacts may have one or more checksum children
• The artifacts tag itself is an optional tag in a release group.
• The location tag must point to a direct download location (not some website) of a tarball
• The location tag may be present more than once in case there are different mirrors available and no CDN is used
• The platform property of artifact must be a platform triplet for Linux/*BSD

To think about:

• Allow a location type to denote whether the downloaded artifact is an appimage/snap/tarball/etc.? (This would cover things discussed in Add release download URLs to metainfo files? #154 as well)