-
-
Notifications
You must be signed in to change notification settings - Fork 18
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
Consider to bundle the runtime #61
Comments
In either case, you'd need to touch the build system. But then again, there is no reason not to keep those stable. |
I've replied to that in the other issue. I won't copy-paste it. |
E.g., if we call "type" "version" one day, as we had brainstormed at some point in time.
As evidenced today. When either happens, an older Would it be OK for you to bundle at least default or fallback versions? If I think about it, since an AppImage is supposed to have no dependencies other than what comes with the operating system, I think that's the only way to be in line with our "one app = one file" mantra. |
By accident or so. Not by intention. It's been fixed. |
Just make releases and reference a specific release from appimagetool. Running cutting edge will lead to problems. |
Then
For these reasons I really think the runtime needs to be bundled. |
Can happen anytime again. In fact, will happen again - only a matter of time. |
We've agreed to do those more than once because they make sense and I think you should remember at least that. Nobody likes doing it, but it's a sign of project maturity. People use these tools and the runtime every day.
Nope. Nobody needs to maintain old releases. They should not be deleted. But every project has a reasonable support policy. If the policy is "we don't support anything but latest", then that's fine. If it's broken, go update first, then retry.
Not necessarily. People can be forced to update their tooling occasionally. Plus, hosting on GitHub is free.
True. I'd prefer to download the latest version by default. But then again, downloading allows for implementing all kinds of varieties: downloading latest continuous release, downloading latest stable release, downloading a specific version, ... It just automates the step of downloading the runtime. In my opinion, it wouldn't be a big deal if people just had to download the runtime anyway. Then, you don't have any responsibility on which versions they use. However, that's a big usability downside. But, then again, that's how all the other solutions work: you need to specify versions somewhere.
I've proposed a specific download API that we control since I think as early as 2018. You're not a fan of hosting this yourself, though. This would give us control however. As said, depending on the support policy, we could introduce such breaking changes anyway.
I'll think about bundling them again. But I have so many good reasons not to do so. And we've talked about all of them. I'm not 100% happy with the downloading either, but then again, it's working just fine for so many people and it's way better than all previous attempts. In any case, you wouldn't want to automatically fall back to some old specific version. What if that one's inherently broken? Or maybe a security fix has been released in the meantime and people start exploiting the fact that appimagetool would insert an old, broken one as soon as the Internet connection is cut? |
You can say that about any bug. See, today you introduced a few quick fixes. Hours later, they're unnecessary because the root cause has been fixed, causing additional work. |
The downloading mechanism is not robust over time:
Errors caused by this should happen at build time, when developers can fix it, rather than at run time, when users are affected.
Hence we should consider to bundle the runtime in the appimagetool AppImage.
But the bare minimum needed, I think, is that changes in type2-runtime need to trigger a build of appimagetool. So that any potential issues are seen by developers immediately.
The text was updated successfully, but these errors were encountered: