Closed karsai5 closed 1 year ago
2 months it's not that long. I often reach out to Pixelfed dev when it's been a while without release and a lot of features where added, but ultimately we depends on its schedule (and yes, I'd like to see more regular releases, but I don't do the work).
Moving from releases to commit upgrade it a lot more work with no stability guaranty. You may introduce bugs, that might be hard to detect, and then need to upgrade, don't know which commit to pick, introduce more issues, and so on. That's the main reason to keep using releases.
We seen this when trying to upgrade to some commit to allow post edition (which was a huge game changer), that was merged right after the release (hence it was only a small change). And then the hot fix 1. And the hot fix 2. And the hot fix 3. And the bunch of commits on other thing that were merged meanwhile.
As a result I'm strongly against moving away from releases for the stable version (and even testing, as it is used for beta-testing the master branch next version). If anyone if willing to make a PR for a specific commit number for reasons, fine, do it and submit it so other people are aware, and then people can try it if they want. But I'm not using this for stable versions.
Thanks for the context @lapineige, and thanks for maintaining this package! It is by far the easiest way to get Pixelfed up an running
There hasn't been an official "release" of Pixelfed in over 2 months now and a number of features have been added since then (Instagram importing etc.)
Even before this break it can be seen from the dates of the tags https://github.com/pixelfed/pixelfed/tags that releases are pretty erratic, sometimes having a couple in a month, then not having a release for months at a time.
Is it worth having pixelfed_ynh periodically pinned to certain commits? That seems like it could be a lot of extra work but I'm not sure how other YNH apps are maintained so I don't know if that's common practice.