do not provide the `main` branch as "latest/stable"

[firewave]

The current version shown is 2.13.99 which indicates that it is the development version of 2.14. This should not be offered as "stable" as it isn't. It might make sense to offer it as "latest"/"dev" if you can have different channels via Snapcraft.

The "stable" should also be build from the version tags. The latest is 2.13.2 - https://github.com/danmar/cppcheck/tree/2.13.2.

[firewave]

Having taken a look at what is provide, there are only two channels which should be maintained:
latest/stable - build from the latest version tag (obviously in sync with latest/beta and latest/candidate as we do not have such versions)
latest/edge- build from main branch

latest/edge already seems to be fine.

latest/stable appears to be outdated as it has an older date then latest/edge. Until that is actually replaced with a proper stable release it should be in sync with latest/edge. If you cannot push an older version as the current one that needs to be done until 2.14 is out . Or you need to use a temporary higher fake version like 2.13.100 for now.

I also wonder if there is a way to somehow add the commit hash to the edge build. Not essentially in the version but maybe just some descrption.

[iosifache]

The current integration between the Snap Store and GitHub builds the snap and publishes it to the edge channel. To publish to the stable channel, a quick edit in the Snap Store UI is required.

An alternative is to build and upload the snap using GitHub Actions and workflows. However, this process can be error-prone, as GitHub only supports one architecture available in Launchpad, and you would need to leverage QEMU virtualisation for the other builds.

With this in mind, I would suggest sticking to the current approach. I can monitor new releases on GitHub and, when I see a stable release, I can access the Snap Store UI and promote the edge release to stable.

If you prefer immediate publishing of new releases to the Snap Store, we can also discuss transferring the snap and this repository to the Cppcheck development team. Once we resolve issue #3, the Snapcraft definition file, snapcraft.yaml, will remain the same. The only recurring tasks will be the aforementioned ones.

[firewave]

If you prefer immediate publishing of new releases to the Snap Store, we can also discuss transferring the snap and this repository to the Cppcheck development team.

That would probably the bestest approach. The problem is that no one is familiar with it (yet) and unless their is the initial automation and some documentation it is rather hard to maintain. I's also a time thing.

As releases are not very often I think this current approach will be fine temporarily. I still have too many open tasks so I didn't look into yet but I hope to finish up some of them soon so I would have less on my plate and could look into it.

[iosifache]

I feel you..

(Please don't forget that your work is highly appreciated in the open-source space. Keep up the great work with Cppcheck!)

I would argue that the maintenance cost of this would be minimal. Some overall steps here would be:

1. Transferring the repository to a core maintainer or a Cppcheck organisation, if you have one (one-time task);
2. Transferring the repository to a core maintainer (one-time task); and
3. Entering the Snap Store UI and following the aforementioned release (only when having new releases).

For the last step, I would be more than happy to create a short guide that could be included in the repository.

If this still sounds overwhelming for your current schedule, we can freeze this and restart the discussion in the future 🙌🏿