Make linuxdeployqt -g aware of feature branches and PRs

[probonopd]

From #518 (comment) @dirkhh

one thing that I find challenging... if I want to play with this on a feature branch (I'm working on debugging a problem, I need AppImages to deal with that)... if I push to that branch, that becomes the latest pre-release binary.
Would it be possible to use continuous for master and continuous-branchname for other branches and offer them separately? Or is this beyond what GitHub/Travis can do?

[dirkhh]

I'm not asking to support autoupdates for the branches - that really only makes sense for master, IMHO.
I think the easiest way to do what I want is to only run the uploadtool on master and on other branches to rely on transfer.sh - but having them all in the same place would be much more elegant and easier.

[TheAssassin]

@dirkhh that should be possible by instructing uploadtool to create a prerelease for every branch. With some bash magic one just has to add a suffix like continuous-<branchname>, then use that tag instead. You can even implement auto updates for that. We just have to think about how to implement that in a reliable and automagic way.

[dirkhh]

see probonopd/uploadtool#13

[probonopd]

Let's see how people use this, and then revisit the question what would be the right thing to do regarding the binary delta updates. This might be a way to do different release channels, like continuous, beta, release, etc.

[dirkhh]

Different channels are definitely important - and given that I tested a dozen AppImages or two in the last few days, I certainly see the value of the delta update. What's the state of that? Is that ready for testing? I was too focused on fixing the Qt issues to really follow that...

[probonopd]

No, I haven't started working on this as we should agree on how it is supposed to work first.

This is the current logic:

AppImageKit/appimagetool.c

Lines 749 to 754 in 6f3138f

	gchar *channel = "continuous";
	if(travis_tag != NULL){
	if((strcmp(travis_tag, "") != 0) && (strcmp(travis_tag, "continuous") != 0)) {
	channel = "latest";
	}
	}

So, everything that is not tagged continuous will get the update channel latest.

What would be a more suitable logic?

[dirkhh]

and channel 'latest' is the releases, correct? So that's annotated tags? Or how is that determined?
The way Subsurface uses this (and the way I modified the uploadtool) it would be reasonably easy to say that you have an unlimited number of channels:

• "continuous"
• "<branchname>" (which is searched for as tag "continuous-<branchname>"
• "release" (which is searched for as "latest", I guess?)
  Does this make sense? Am I answering the right question? :-)

[TheAssassin]

Delta updates are already available, the new https://github.com/AppImage/AppImageUpdate is ready for testing.

@probonopd has found a usability issue because AppImageUpdate by default updates the old file, i.e., when you put a hash or something similar into the filenames of your AppImages, the local file name wouldn't change, which might be a problem with applications that don't have a --version including that information as well.

I personally don't like having any version identifier (other than the "update channel") in the filename, but I see it's a valid use case, so we're moving that behavior to a separate flag (-O / --overwrite), create a new file and ask whether to remove the old one afterwards.

If you want to try it in the meanwhile, head over to https://github.com/AppImage/AppImageUpdate/releases and grab a copy of the standalone application.

[probonopd]

"release" (which is searched for as "latest", I guess?)

latest uses GitHub functionality to resolve to the newest release not marked as prerelease on GitHub Releases.

Delta updates are already available, the new https://github.com/AppImage/AppImageUpdate is ready for testing.

Well, I guess @dirkhh is more interested in the upcoming libappimageupdate which will make it possible to be neatly integrated into the app version check dialog. But yes, the guts are there... thanks to @TheAssassin

[probonopd]

The way @dirkhh is currently using continuous-* "channels", they are like feature branches, which means that most likely at some point they will go away, when they are folded into a real release or are discarded altogether (correct?). So the question is what should happen when a continuous-* channel is no longer available on the server but the user wants to update such an AppImage. Should we fall back to trying continous, or latest?

Or am I overcomplicating things here?

[TheAssassin]

A fallback might not be the best idea, updating from a "foreign" channel might not be intended. You can't really make an assumption on when a channel "is no longer available", you're speaking explicitly about the GitHub releases mechanism, and there are quite a bunch of cases in which a release might be unavailable for seconds/minutes, but as we don't keep the state locally, saying "this is no longer available" isn't possible in a reliable way, at least to my best knowledge.

[probonopd]

Maybe we could make it follow the GitHub flow, i.e., find out what source code was merged where (using the GitHub API) and follow that... or maybe that is totally crazy.

[dirkhh]

(back from breakfast - time zones are fun)
Yes, the branches for us are usually fairly short-lived - but some other projects have continuing releases in two branches and those were the ones I was thinking about.
I think the library should tell the caller "can't find an update for this channel" if the channel disappeared. And the documentation should state "this could be a temporary situation, or this could mean that the branch no longer exists" and then the app can decide what to do.
It would be nice to have an option to do a delta update to a different channel.
Have the API give you a list of the currently available channels and when the last build was released and offer to cross-update to one of them.
So if I'm on the "newMapWidget" channel and keep testing this and then the branch goes away because it was merged, most likely I KNOW that I want to switch back to continuous.
And even better, if I'm on continuous and want to test the "dontDisconnectFacebook" channel, I could switch to that without having to download 80MB... I like that last example a lot because that's a very very frequent use case for our testers.