search

probonopd / go-appimage

Go implementation of AppImage tools
MIT License
812 stars 71 forks source link

provide persistent releases #275

Open dehesselle opened 7 months ago

dehesselle commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

pbs3141 commented 7 months ago

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 commented 7 months ago

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...

pbs3141 commented 7 months ago

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

probonopd commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

[...] 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 commented 7 months ago

OK, a PR would be appreciated. Thanks!