You should note that versions are actually only strings for user convenience and are not used for anything beyond this in the snap ecosystem. versions have no influence on the ability to release something to stable, the actual control of different package versions is in the hands of the “revision” parameter.
in that light it would be interesting what error you get if you try to release that snap to stable since even if you called the version “d.e.a.d-b.e.e.f-0.1.2.3” the snap ecosystem should not care.
regarding getting the right version from upstream, you should try to set source-tag: v0.6.0 in your snapcraft.yaml, that should pull exactly this upstream tag with a proper version string (you indeed need to bump that version if upstream does a new release).
Yeah, version strings are totally within your control as the developer of the yaml. There’s a few ways to manage this. Hard wire the version in the yaml with version: somestring. Use a script to determine the version with version-script: somecommand (such as git describe --tags). Or via adopt-info and snapcraftctl set-version somecommand inside the part override-build section.
The obs snap uses the latter which you could use as a reference. We use the logic there to build either a stable snap (which upstream do a new release) which gets us a nice tidy version number, or unstable builds of master, if there’s no upstream release newer than the last one we put in the beta channel.
If no such revisions are available you may always push a build of the specified source-tag to the edge channel, promote the edge channel snap revisions to the stable channel, then re-promote the previous edge channel snap revisions back to the edge channel:
build.snapcraft.io can not rebuild a previous revision from GitHub
Install all the snapcraft tools locally, and snapcraft login
Clone your repo locally and check out the desired revision
If your snapcraft.yaml version field is git and you make any modifications to the repo, you must hard-code the new version. If you don’t, it will be tagged as dirty
Build a package for each arch:
for arch in s390x ppc64el arm64 armhf amd64 i386; do snapcraft cleanbuild --target-arch "$arch"; done
Push each package:
for f in *.snap; do snapcraft push "$f"; done
The grade field in snapcraft.yaml is not for the software being packaged, but for the packaging process itself. When autobuilding from GitHub with version: git, it should be left on stable at all times since build.snapcraft.io does not differentiate between building a release commit and any other commit.