Glimpse: Snapcraft did not update to latest release and may be using wrong branches

[TrechNex]

Describe the bug

Since the release of Glimpse Image Editor 0.1.0 our branching and tagging strategy has changed, so the code provided to us by the third party packagers @hellsworth and @psymole will need to be updated.

To Reproduce

Steps to reproduce the behavior:

1. Try to update or install Glimpse Image Editor through Snapcraft
2. It will install 0.1.0

Expected behavior

The current stable should be 0.1.2, and the beta channel should pull from beta branch.

Desktop (please complete the following information)

• OS: Linux

Additional context

Add any other context about the problem here.

dev-g210 contains development changes that would be well-suited for "edge" channel
beta-g210 is updated whenever we start beta testing, so would be good for "beta" channel

Tags will always be applied to the stable "release" branch we merge modified beta changes into.
v0.1.0 is a tag on dev-g210
v0.1.2 is a tag on glimpse-0-1
v0.2.0 and v0.2.x releases will be tagged on glimpse-0-2 when we create that branch

[TrechNex]

The reason we haven't just done a stable-g210 branch btw is that we may need to backport changes to past versions based on older editions of GNU Image Manipulation Program if we discover major bugs.

This is why each major 0.n.0 release gets its own "stable" branch that we make bug-fixes against. It also means we can do work on the next major version at the same time as supporting existing builds.

A solution where we can modify tag and branch for Snapcraft to track would be handy as we can try and do that with each release instead of asking for regular changes. :)

[TrechNex]

Also cc @BrainBlasted as this branching strategy was also partly his idea. I'm mostly following it because it follows what upstream is doing.

[TrechNex]

For reference I have created a new 0.1.4 release because I think we need to get docs, packaging & backporting right before we try to do a major rebase.

[hellsworth]

Thanks for the details about what should be in each snapcraft branch. Right now everything in the snapstore (all channels) have been built from the v0.1.0 tag but I like the idea of improving the map of branches to what the user can install. I do have a couple of questions though:

beta-g210 is updated whenever we start beta testing, so would be good for "beta" channel

Ok I can add a snap for this channel. How would you like it to be versioned? The options are some hardcoded string or a git hash fingerprint.

v0.1.0 is a tag on dev-g210

If I checkout dev-g210 and do git describe --tags, the only one I see is v0.1.0-2-gaa7d55a47c. This tag is from Nov 22, which is pretty old. Is this what you want built from the dev-g210 branch and put in edge?

v0.1.2 is a tag on glimpse-0-1

If I checkout glimpse-0-1 and do git describe --tags, the only one I see is v0.1.0-64-g94aee3304f. This tag is much more recent, from March 2. Is this what you want built from the glimpse-0-1 branch? Also what channel would you like this to go into? Maybe candidate? Typically the channel identifies the risk level, going from most risky (edge) to least risky (stable). Read more about the risk levels usage.

[hellsworth]

Also what do you envision for promoting things to the stable branch? If you would like to choose when/what to promote and do that, I could add you as a collaborator in the snapstore if you like. I'm also happy to promote whatever/whenver you like. But we should have _something_ in stable because that is what the user will get by default if they don't specify a channel.

[TrechNex]

tbh I'm a bit confused by the results coming back from the git describe --tags command (I am reproducing your results) because the v0.1.2 tag most certainly exists 😅

I think the most straightforward thing for beta and stable would be to hard code tags. I get the impression that's a thing we would have to do anyway for Flathub, so I anticipate adding "beta" tags in future.

For edge channel I was assuming that would follow the tip of dev-g210, but if that's not possible then a commit hash would do fine.

[TrechNex]

For the sake of beta-g210 for now I'd suggest just using a commit hash, because 0.1.2 is released now and it doesn't make much sense to create a tag for it.

[TrechNex]

Also what do you envision for promoting things to the stable branch? If you would like to choose when/what to promote and do that, I could add you as a collaborator in the snapstore if you like. I'm also happy to promote whatever/whenver you like. But we should have _something_ in stable because that is what the user will get by default if they don't specify a channel.

The other way to do it would be to make it straightforward for us to edit in build-aux/snap. We could then set different tags/commit hashes on each branch, and all Snapcraft has to do is keep an eye on the branches.

[hellsworth]

For the sake of beta-g210 for now I'd suggest just using a commit hash, because 0.1.2 is released now and it doesn't make much sense to create a tag for it.

@TrechNex what commit hash would you like to use for this? I was going to just go with the most recent one but I just looked and it the beta-g210 branch might need a rebase on dev-g210. So just let me know what hash you want used.

[hellsworth]

For edge channel I was assuming that would follow the tip of dev-g210, but if that's not possible then a commit hash would do fine.

This is totally doable. If we track the most recent changes on dev-g210, I'd prefer to use a git hash version in the snap rather than, 0.1.0 which would be misleading IMHO.

[TrechNex]

@TrechNex what commit hash would you like to use for this? I was going to just go with the most recent one but I just looked and it the beta-g210 branch might need a rebase on dev-g210. So just let me know what hash you want used.

That's the correct approach, just use the latest commit hash. As and when we do the next beta we'll need to do a rebase, resolve conflicts from some git cherrypicks I did then make some metadata updates, but that will always be done in a separate branch that gets merged in with a PR.

[TrechNex]

Confirming that this is now fixed.