Can you elaborate? snap refresh --list already shows version and revision:
$ snap refresh --list
Name Version Rev Size Publisher Notes
core24 20250729 1151 70MB canonical✓ base
snapcraft 8.10.2 15369 76MB canonical✓ classic
toolbox 0.9.36 4014 68MB ondra✪ -
It is missing held snaps though.
Sorry, I meant both the current version and to-be-refreshed one; especially for held packages (where you opted in for more control) it would be nice to have a one-stop command to see what was the old state (version,rev,epoch), what would be the new state (version,rev,epoch), when would it happen (hold, hold period). Epoch is only really important on epoch change I guess?
I did not find a forum tool to split the post, so I recreated it at Feature Request: restrict snap run to certain groups (for a single snap)
FYI improved progress reporting will likely be included in snapd 2.72.
Edit: landed the branch just now
Not sure this is a papercut; but what would be good is support for suggested changes of tracks/channels. From user perspective, one subscribes the channels not only to get that specific version, but also to a specific upgrade policy. So e.g.for freeorion we have old versions of the game around, which are different from newer versions and it might make sense to play the old version, e.g. if you do not like the new features (happens quite often). As that is a local game for gaming rigs and not asking a lot of permissions, that is also kind of ok security-wise that those dont get updates. These channels should never be closed. With newer releases there should sometimes be upgrades. If you have a game running you would not want to have the rules changing (and savegames be incompatible).
Anyway, if I publish a new version/incompatible update Id like to give the options to the user. So when distributing the snap i like at least once to present the option to switch track/channels or maybe even temporarily(?) hold updates. And probably a way to review that decision late and maybe choose another option.
Currently snapd does not support the users in choosing which channel to subscribe to. It does not tell one what the channel and updates to the channel mean.
I propose adding a per-channel description which can be shown in snap info next to the corresponding channel.
channels:
v0.5.1/stable: v0.5.1.1-rc1 2025-06-26 (491) 367MB - "The current release as of July 2025. Main features: Opinion, Annexation"
v0.5.1/candidate: ↑ "Release candidate for v0.5.1 an updates"
v0.5.1/beta: ↑ "Inofficial test builds from master branch"
v0.5.1/edge: ↑ "Only for developers. Weird changes without notice."
latest/stable: v0.5.1.1-rc1 2025-06-26 (491) 367MB - "The current release. Will be upgraded to a new release when that becomes stable"
latest/candidate: ↑ "Release candidate for latest/stable from master branch"
latest/beta: v0.5.1.1-rc1 2025-06-16 (491) 367MB - "Weekly test builds from master branch"
latest/edge: 2025-07-25.8f7e1a0 2025-08-12 (495) 367MB - "Only for developers. Weird changes without notice."
v0.5.0/stable: v0.5-rc3-38-g59084dbca 2024-03-20 (431) 215MB - "April 2023 release. Main features: Stability, Policies, Influence."
Channel description is shown on the far right; probably needs some solution for the spaces in the descriptions (all the other values do not contain whitespace)
This originates from the thunderbird monthly track request discussion; it is currently very hard to understand what each thunderbird channel means. And snap info (or the other package management UIs) seems the perfect place to show that info to interested users.
This feels like a thing that’s entirely in control of the publisher. Request and use tracks to separate versions, use snapstore page or some other form of communication to convey information about suggested/preferred tracks and version incompatibilities. All those mechanics are store side IMO. Snap store (the app) could take part in it, similarly like Steam (the client) shows various information about games and announcements from game publishers. I’d suggest to try to poke the snap store application folks.
I like the idea but it’s way beyond what I can do as part of this. The information needs to come from the store and be filled by the publisher, i.e. a modification of the existing store APIs is required, which comes with it’s own set of problems and involve a couple of teams.
I just got a request from a customer who wants to find out the currently running snapd version from an application snap on Ubuntu Core. While they could achieve that by granting the app snap snapd-control and craft a REST API call, it is rather overkill to grant such wide permissions just to find out the running snapd version.
The snapctl command already offers a bunch of system wide info to query from within an app snap, it would be nice to have a snapctl version command implemented that returns the same output as snap version …
(I filed a bug for this too)
Looks reasonably small. Maybe I can fit it in the next pulse.
FWIW. this information is available without needing snapd-control:
[root@galeon snapd]# $SNAP_COMMON/test-snap debug api --disable-auth /v2/system-info |grep '"version":'
"version": "2.71-1"
(though, I’m using snap debug api with some tweaks that haven’t been upstreamed yet)
In the field of components.
It would be nice to add support for something like:
assumes:
# This snap requires the "components" feature to work
- components
Looks like components aren’t listed on the snapd features module.
Edit: Or this couldn’t be listed anyway because this isn’t a snapd feature, but a feature of snaps instead? Would be that the case?
I just noticed while looking at someone elses snap changes output that the
snap $foo has running apps
action actually logs as an ERROR entry in snap changes, this really shouldn’t be an error but rather something like INFO or at most a WARNING … (not sure how much of a papercut changing this is though)
For a normal user it looks rather scary and is somewhat indicating that the update actually failed (the next line in snap changes is usually indeed the successful update that occured automatically when the app was closed)
Had a chat during standup about this. Unfortunately it may be too late, in the sense that a version of snapd supporting components is already out there. Your best choice at this point is using something like:
assumes:
- snapd2.70
A post was split to a new topic: Parallel instances and content connections
Since it’s a trivial change I picked it up for this pulse. The output is as follows:
$ snap run --shell test-snapd-sh-core24.sh -c 'snapctl version'
snapd 2.71+g228.5f67693a58-dirty
which follows format as snap version:
$ snap version
snap 2.71+g140.3a019dc-dirty
snapd 2.71+g228.5f67693a58-dirty
series 16
arch -
kernel 6.16.7-arch1-1
Awesome, though I think you replied to the wrong post 
I found one which should be relatively easy to patch:
When switching a snap from a local build(with snap revisions like x1, x2, …) to one of the store distributions, the following broken message is printed:
$ snap info scrcpy
...stripped...
channels:
latest/stable: 3.3.2 2025-09-17 (457) 98MB -
...stripped...
installed: 3.3.2 (x1) 98MB -
$ sudo snap refresh scrcpy --amend
scrcpy 3.3.2 from sisco311 refreshed
Channel for scrcpy is closed; temporarily forwarding to stable.
This line↑
Thanks, filed https://bugs.launchpad.net/snapd/+bug/2125344
One papercut that’s been bothering me for a while now is that the outputs of commands like snap list, snap refresh --list, snap services are hardcoded. We have multiple examples of tools written in Go supporting customization of their outputs.
This is usually implemented by using the Go text/template engine and exposing a command line switch to apply the user provided format instead of the built-in one.
I think it’d be great if one could pass --format=.. switch to have snap list produce output which is directly usable in scripting without or with limited processing.
edit: filed Bug #2127086 “User provided output formatting for various snap c...” : Bugs : snapd
One thing I’d love to be able to is to use a wrapper script for my graphical snaps that checks if the app started successfully after upgrade and in case it does not exit 0 on next start does an automatic roll-back to the former version…
While I can add checks in the various refresh hooks and make them fail to cause automatic revert, this will not help at runtime with user started applications.
For a wrapper scenario with a runtime check as described above it would be needed that the wrapper could execute something like:
snapctl revert
Which is not available today …