Add the new artifacts tag to releases

[ximion]

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)

[hughsie]

Firmware is type=binary? What would the platform be for a UEFI executable?

[ximion]

@hughsie The platform would either be not set, or uefi or firmware, I guess.
Or we are being very pedantic and set a device identifier as platform.
Since for firmware components programs that deal with AppStream information already know that they're dealing with firmware, there wouldn't be a need to repeat that fact again for release artifacts, I think.

[probonopd]

Would it be useful to distinguish between a permalink to "the latest AppImage in the beta channel for x86_64" vs. a deep link to "the AppImage for version 1.2.3 for x86_64"?

I guess what I am asking for is a way to specify artifacts without specifying a particular release to attach them to, but rather a "channel" (such as continuous, nightly, alpha, beta, release, lts, oldstable, etc).

My use case: On https://appimage.github.io/ we are using AppStream files shipped inside AppImages to enrich the "product detail pages", e.g., with buttons to the download page. Right now we can't have a button "download beta", "download continuous" or such; having this possibility would be useful. Constraint is that we can't track each build of each app, as this would generate way too much polling. We never know when an upstream author puts out yet another (continuous) build.

[ximion]

@probonopd

Would it be useful to distinguish between a permalink to "the latest AppImage in the beta channel for x86_64" vs. a deep link to "the AppImage for version 1.2.3 for x86_64"?

There would never be a "latest" link, because the artifacts are tied to a component release (which has a version number).

I guess what I am asking for is a way to specify artifacts without specifying a particular release to attach them to, but rather a "channel" (such as continuous, nightly, alpha, beta, release, lts, oldstable, etc)

AppStream supports release types, so you could have a (perpetual?) release of type="development" which just links to the latest release via an artifact. So you could have at least a "download release" and "download development snapshot" button.
With AppImages, I wonder whether the artifact tag also should have a bundle property as well, to identify how exactly the release is packages (could have values of e.g. flatpak, appimage, tarball, ...)

[ximion]

This is now documented (af05e8f) as well as implemented (13fc435).
The appstreamcli validator will be extended shortly as well to validate the new tags properly.