Comments (10)
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.
from go-appimage.
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.
from go-appimage.
https://github.com/probonopd/go-appimage/tree/master/src/appimagetool#installation-and-usage
from go-appimage.
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.
from go-appimage.
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...
from go-appimage.
Ok, I was assuming it would be easy to just tell GitHub to keep the continuous releases around.
from go-appimage.
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!
from go-appimage.
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.
from go-appimage.
[...] 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.
from go-appimage.
OK, a PR would be appreciated. Thanks!
from go-appimage.
Related Issues (20)
- Continuous build has versioned filename and thus can't be downloaded HOT 2
- Cannot see volumes come and go HOT 4
- appimagetool -s deploy breaks things like qApp->applicationDirPath()
- appimaged fails to parse entire directory HOT 9
- [Feature request] "Simple" mode, please? And / or some real-life usage examples in the docs?
- AppDir could not be identified: ./usr/bin does not exist HOT 6
- Guessed qt_prfxpath wrong (Qt 5 gets deployed instead of Qt 6) HOT 12
- Properly handle SDL2 HOT 4
- AppStream validator gives wrong results and can't be disabled HOT 18
- 'Invalid desktop file' with exit status 1 on Debian HOT 3
- [Question] What to say to app dev when "is not a proper AppImage", "too short" ? HOT 18
- Howto for users is missing. HOT 3
- Appimages won't work with fuse3 unless fusermount is symlinked to fusermount3 HOT 4
- How to launch without FUSERMOUNT_PROG variable? HOT 5
- appimagetool don't bundle `immodules.cache` neither set `GTK_IM_MODULE_FILE` HOT 1
- appimagetool don't configure `loaders.cache` HOT 5
- Crash when application has .svg instead of .png icon HOT 4
- Question/Feature Request: Is the "Applications" directory required? HOT 2
- Stack overflow gathering libs HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-appimage.