I’m on the fence between, say, go@1.7/stable and go/1.7/stable… the latter seems more clear for some reason. Perhaps because it gives a feeling of parenthood with stable/1.7 being under “go”, which more correctly reflects reality than the idea of go@1.7/stable, which makes it feel slightly like 1.7/stable is a place where we can find more things than simply go itself. The use of a single punctuation character also feels like a win in this case… less noise.
I’ve just been trying to come up with potential issues that might exist with this syntax. So far it seems fine, because we never have a context where both a channel and a snap name would make sense. So the potential ambiguity which might happen with snap name being interpreted as a track is irrelevant.
So yeah, this feels a bit nicer. Can anyone come up with relevant issues with that?
If that goes forward, we should accept it in the command line as well.
As others pointed out, there’s a bit of confusion here. We have a good document explaining the terminology in detail.
The base should be installed just as usual.
As @wgrant pointed out, it would not make sense to allow them to be installed by default. I suggest supporting a flag such as –allow-classic in snapcraft which would enable these snaps to be installed, and when it’s not provided failing with a clear message.
Agreed. Would just like to emphasize here that bases are strictly defined rather than just preferred.