Open the Snap Store, click on any application you like – you will now see a page full of useful tidbits – screenshots and videos, application description, last update, license, contact data, and other information. The data shown here is often the first impression the user gets about the software, and can be a deciding factor in whether they want to install and use the application.

Keeping application metadata accurate and up to date is no small task, and requires attention from the publishers. Today, some parts of the metadata update process are less than ideal, and can introduce management overhead. In today’s article, we’d like to talk about an important feature change, which will streamline metadata handling, and make the snap publication process more robust.

To meta or not to meta?

In the current implementation in the Snap Store, metadata is parsed and extracted on every snap upload until the publisher makes a manual metadata change in the Store. This means that, in some scenarios, there could be a mismatch between the snap data and the Store data, making application lifecycle management less elegant.

Since the Snap Store does not inform the snapcraft users of the mismatch, the users must then manually push or force-update the metadata from the command line (using snapcraft’s upload-metadata feature). This can be cumbersome when publishers handle a large number of snaps, manage multiple tracks and applications, or frequently update their software.

Update Metadata on Release (UMoR)

The new proposed mechanism will allow a more robust handling of metadata:

• By default, the Snap Store will extract metadata only from the first revision of a snap.
• When there is a release to the stable risk channel for the default track, the Snap Store will update the metadata by extracting information from the released revision.
• Existing snaps already in the Store will have the UMoR setting enabled.

If a publisher decides to turn the feature off, then the updates will require an explicit, manual update through the store Web UI. Later on, should the user decide to enable UMoR, the Snap Store will warn the user of any potential conflicts (metadata mismatch). In this scenario, the manually edited information will then be overwritten with the next release.

On the command line, snapcraft will also inform the user of any potential conflicts for metadata uploads, and will require the use of the –force flag, to avoid any accidental deletion of metadata manually inserted into the Snap Store.

snapcraft upload-metadata kompozer_4.snap
Uploading metadata from 'kompozer_4.snap'
Metadata not uploaded!
Conflict in 'icon' field:
In snapcraft.yaml: None
In the Store:      'https://dashboard.snapcraft.io/site_media/appmedia/2020/05/kompozer.png'
You can repeat the upload-metadata command with --force to force the local values into the Store

Any manual change of the metadata in the web UI will set UMoR to off. The reasoning behind this is that typically, a manual, interactive change suggests the publisher wants to prioritize manually-entered metadata over what might be contained in a snap revision. In order to avoid overwriting any manually-entered data, the feature is turned off in this case.

Summary

A smooth, efficient developer experience is a crucial part of any software ecosystem. This also includes metadata, as it dictates how easy it is for developers to make changes to their applications, and how easy it is for users to discover software and make educated decisions based on presented information. Good metadata can help make your snap shine, and invite people to try your tools and programs. We also invite you to take a look at our Snap Store tour, to familiarize yourself with the different settings and options available.

We hope you will find today’s announcement useful. If you have any concerns or suggestions on the Snap Store or the metadata upload functionality, please join our forum and tell us about it.

Photo by Mathew Schwartz on Unsplash.