provide persistent releases

[dehesselle]

Hello,
would you consider providing persistent releases as well? Having only a continuously updated prerelease with unstable links makes life hard for automated builds that want to use this tool.

[probonopd]

Thing is, only the latest build is supported. In the README, there is a snippet that shows how to get the latest download URL easily.

[dehesselle]

Having old releases doesn't mean you have to support them, but that's just my 2ct.

Can you point to the snippet you're referring to? I'm not seeing it.
Of course I can do something like

URL=https://github.com/probonopd/go-appimage/releases
FILENAME=$(basename -s .zsync $(curl -L $URL/expanded_assets/continuous | grep -Eo 'continuous/appimaged-[0-9]+-x86_64\.AppImage\.zsync'))
echo "$URL/download/continuous/$FILENAME"

but I don't think that's what you mean.

[probonopd]

https://github.com/probonopd/go-appimage/tree/master/src/appimagetool#installation-and-usage

[pbs3141]

Thing is, only the latest build is supported.

That's what this issue is specifically asking to change.

Having to always use the latest build is bad for reproducible CI, and allows CI to break if bugs are introduced upstream.

[probonopd]

Yes, I understand the need but unfortunately at this time I can't commit the time for doing this on a regular basis.
(In the meantime, you could save a private copy of a known good build and use that in your CI.)

If we started to make releases, you could count the time until someone would start complaining that the releases don't happen regularly or often enough...

• Any timeline for an updated version? AppImage/AppImageKit#1305

[pbs3141]

Ok, I was assuming it would be easy to just tell GitHub to keep the continuous releases around.

[probonopd]

Well, it would - but then we would end up with thousands of builds (if we can't find a clever way to clean up all older than X). Any ideas welcome!

[pbs3141]

Any ideas welcome!

Just embrace the thousands of builds? Or rather tens, going by the commit history in the last year.

In the meantime, you could save a private copy of a known good build and use that in your CI.

Embedding binaries in CI is not good; that's precisely what allowed the XZ backdoor.

[dehesselle]

[...] unfortunately at this time I can't commit the time for doing this on a regular basis.

You're overthinking this. We would not want you to do anything special or different compared to continuous releases.

Well, it would - but then we would end up with thousands of builds (if we can't find a clever way to clean up all older than X). Any ideas welcome!

I suggest a very simple release scheme: have the GitHub workflow create a permanent release when you push a tag. This is easy and no maintenance burden at all: you just decide at some random point of your choosing "ok, I've collected a couple of changes, I'll tag it v123" and that's it. You don't have to write release notes and there's no need to burden yourself giving the version number any meaning.
I can make a PR if that's something you'd be comfortable with.

[probonopd]

OK, a PR would be appreciated. Thanks!