### What needs to get done At present if a snap uses `stage-packages`, the generated `manifest.yaml` file will be annotated with the versions of those packages used to build the snap. If a snap uses `stage-snaps`, no such annotation is added: while we can tell what channel was used, we don't know what revision that corresponded to at the time the snap was built. Maybe something like the `stage-packages` syntax would be appropriate. Something like this? ```yaml stage-snaps: - gnome-46-2404-sdk/latest/candidate=66 ``` ### Why it needs to get done This idea came up while trying to track down a bug where I had a known working revision of a snap and a known bad one. My usual way of analysing these kinds of problems is to check the `manifest.yaml` file for each snap revision to find their Launchpad builds andthe corresponding git revisions. I can then inspect the changes between those revisions for possible causes of the bug. In this case though, the snap used `stage-snaps`. It was obvious that the two snaps had been built with different revisions of the staged snap, but I had no way of telling what revisions they might be. The two manifests just told me they'd been built with the `latest/candidate` channel of the snap, which had changed between the two snap builds. If the manifest contained the revision of the stage snap, I would have been able to drill down to look at what had changed in that snap.