Why does this project release often while source code did not change?
rayluo opened this issue · 5 comments
First of all, thanks for this project. It comes in handy for testing with different versions of Python without needing to "pollute" the local system.
Why does this project release every several weeks (the latest release was yesterday), while the latest source code was in 9 months ago? What was put into each updated releases?
Hello @rayluo,
the weekly releases are just "opportunistic". That is, every Sunday I regenerate the AppImages in case one of the base Manylinux Appimages has been updated. Thus, the update time in the Python AppImage Releases section does not actually reflect an "update" of the source or Manylinux Docker image. Sorry for this inconvenience.
The issue for me is to synchronize with Manylinux Docker images. That is, ideally, on an update of the latter (on quay.io) I would have to update Python AppImages as well. But, I don't want to check this manually :( Thus, I am updating periodically, whatever the status. But maybe there is a more clever way to proceed. E.g., if quay.io could send some trigger signal to GitHub CI when these Docker images are updated?
Thinking more about it, a solution might be to simply check in my GitHub action if the base Docker image has been updated since last AppImage release, and abort if not. But this check should only run on a 'cron' trigger. Because I also need to update the AppImages on some changes of the python-appimage package, despite the base Docker image might not have changed.
Thanks for sharing the insight.
... Thus, the update time in the Python AppImage Releases section does not actually reflect an "update" of the source or Manylinux Docker image. Sorry for this inconvenience.
FWIW, it is less about the "inconvenience" of seeing some incorrect/misleading release timestamp which most audience might not even notice. It is more about the loyal users who subscribe (i.e., Watch) your project's release notification. So, each week they would be greeting with a bunch of release notifications and then they came to check it out and were sure whether they should upgrade.
One of my other projects ran into similar situation. My solution was to add a pesudo-unittest case into my code base. The test case scrapes some data source to get my dependency's latest version number, compares it to a number that I pinned in my code base, and errors out if they do not match. It works!
Hello @rayluo,
I am in the process of rewriting AppImages updates, using pyGitHub instead of gluing together predefined actions. This gives me much more flexibility.
The current situation is that AppImages should be updated selectively now, on a Python version change (patch) in the Manylinux Docker image, or when a new version / abi is added. However, this is done by updating the corresponding Release(s) asset(s). Thus, as far as I understand it does not trigger a notification. It looks like, only when a release is created (e.g. recently with Python 3.12), is a notification triggered. Isn't it?
If this is an issue to you, I could create a "meta" release on such updates, just to notify latest changes (in releases assets). Note that in some (rare) cases I also need to update the AppImage wrapper. In such cases all AppImages are updated, which I am planning to notify anyway.
It looks like, only when a release is created (e.g. recently with Python 3.12), is a notification triggered. Isn't it?
I didn't know, but it turns out I received one notification about the adjustment of the Python 3.12 image here. As long as a release is justifiable, its notification is fine.