Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide persistent releases #275

Open
dehesselle opened this issue Mar 28, 2024 · 10 comments
Open

provide persistent releases #275

dehesselle opened this issue Mar 28, 2024 · 10 comments

Comments

@dehesselle
Copy link

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
Copy link
Owner

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
Copy link
Author

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.

@pbs3141
Copy link
Contributor

pbs3141 commented Apr 4, 2024

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
Copy link
Owner

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
Copy link
Contributor

pbs3141 commented Apr 8, 2024

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

@probonopd
Copy link
Owner

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
Copy link
Contributor

pbs3141 commented Apr 16, 2024

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
Copy link
Author

[...] 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
Copy link
Owner

OK, a PR would be appreciated. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants