Mechanisms for converging store and snap metadata

[galgalesh]

@matiasb

I see your point, and I agree we would probably want some metadata per revision. That will require another discussion and extra work to be scheduled. We are adding a session for next week in the rally.

Has that rally resulted in some decision about per-revision metadata?

Currently, publishing a snap to any channel, track and branch will update the store metadata. This is not the functionality I expect. I expect that only publishing a snap to the stable channel updates the metadata. The user installs the stable channel by default so the user should see the metadata of the stable snap by default. I created a bug report for this but was directed towards this forum to discuss this issue.

We are currently automatically building a snap in the edge channel for each PR, in a branch named after that PR. Much to our surprise, publishing a snap to edge/yaru-pr32 updates the snap metadata. This also has security implications as explained in the issue. If you set up an automatic build system to build and publish each snap to a branch in the edge channel, then anyone who can create a PR can change the metadata of the snap.

@mpt also explains how per-snap metadata isn’t a viable long-term solution.

@mpt

A vendor shouldn’t be prevented from mentioning their app’s cool new features, in the app description, merely because they’re thoughtfully also providing an old version for enterprise/low-end users.

So my suggestion is the following:

1. For the short term, only update the metadata when a snap is pushed to the stable channel.
2. For the long term, consider per-revision or more granular metadata.

Also relevant; the license metadata discussion surfaced the same need for per-revision metadata.