I have plenty of containers with “latest” as tags. That updates every time it starts and is a good thing™ because I get security releases as soon as I reboot not when some overworked admin decides it’s time to get fix their broken package.
Alternatively, clone it and do a git checkout abv234 or whatnot. It hardly is rocket science.
In addtion, Fox just said:
So you kinda want to stay on that.
They update when you do a docker pull not when the container starts.
The difference is that if the container restarts, the latest tag will start up exactly the same.
The fox container will automatically pull new sources when the container restarts.
Obviously I can build my own Docker container pulling source from git.
This is how I used to do it prior to finding the docker-tt-rss container.
If that’s the only supported way to do it, then so be it.
I’m looking around for this but can’t seem to find it.
I can make some PRs to their repo based on your feedback.
it literally is the first result when searching: Search results for 'docker' - Tiny Tiny RSS: Community 
tbh since the closure of Google Reader (half 2013), I use ttrss daily, and all the time it failed was my fault …
And since half 2015, i don’t purge any post (actually 136 feeds with 634565 posts).
Unles you run it via Kubernetes which does a docker pull… Whatever. My setup behaves how I want it to: get me the latest, not the latest when some sleepy admin forgot to update it.
Same thing with ttrss… I am running master which is the latest stable release. Everyone else should be doing the same thing. 'nuff said.
what would be the point? the only thing the version is used for in the first place is so that we here could identify where people are standing to help them. it’s useless otherwise.
a container that updates twice a year, maybe, to an unsupported randomly chosen trunk snapshot which may be entirely broken is somehow better?
i’ll concede that it was naive of me to think that people would bother to understand that in tt-rss case tags aren’t stable releases, especially because it goes against the usual pattern. so partly the blame is on me for making new tags and thus adding to the overall confusion.
this was a conscious design choice based on what i wanted to accomplish with it. if you want to update manually, you can easily make a different container.
this doesn’t in any way absolve this linuxserver garbage from doing everything wrong tho.
Ah I never noticed the call for donations in the docker logs…
Obviously this is not a popular feature that anyone wants so I’m just going to go back to building my own containers.
I really do see the point in forcing those who build container-style installations to get rid of the rationale that using tag-based releases for tt-rss makes sense. I never understood Softaculous’ handling of tt-rss, for instance.
That being said, since I’m running tt-rss on a simple hosting provider, which causes git pulls to be impossible to do directly, I used to run this little update script I wrote in order to keep up-to-date. I keep track of all tt-rss commits via RSS, and update regularly when needed, or if I want to post a question here. The script made use of https://git.tt-rss.org/fox/tt-rss/archive/master.zip, and as such, I would really appreciate if you’d reconsider the now disabled .zip (or .tar.gz) downloads of the master branch.
I fully realize that my situation is likely an edge case, though, and that above all you want to make a statement with it.
I’m frankly amazed it took you this long to do this 
well, main problem was people downloading YY.mm tag tarballs, which are gone now, so i guess there’s no reason to 401 those links anymore. i’ve enabled them back.
i wasn’t really aware how bad it was before i tried that particular docker container. 
Ohhhhhhhh my… annnnnd, 20 characters.
let’s all point at linuxserver dimwits and laugh:
*** IMPORTANT NOTICE ***
THIS IMAGE HAS BEEN DEPRECATED
We are no longer able to ingest tarballs from upstream repo
imagine being so utterly inept (while whining for donations - no i’m not going to let this drop, ever)
e: i guess technically they can enable their shitshow container back because master .tar.gz link is available again, although personally i would prefer them not to.
also: https://github.com/linuxserver/docker-tt-rss/issues/52#issuecomment-562238484
Yeah… It’s no fun when you provide OSS in a manner that’s not supported but expect the dev to support it, then get upset when he says he doesn’t want to.
Thing is users are not going to GitHub for support. They come here, provide no information about their installation, then expect everyone here to magically know why it’s broken.
We deprecated your image because you no longer wanted us to ingest your software, though that message seemed more civil and generic.
I wish you all the best with your project.
OH NO! You’re “hostile”. 
You’ve hurt their little feelers, tsk.
Nope, nobody ever said that. but apparently you’re not capable of understanding the issue… which, frankly, is the problem.
Are you the whiny little git that said “After all, we all do this in our spare time, for fun. It’s no fun to deal with an upstream dev who acts like that.” COMPLETELY clueless about the fact that the “upstream dev” ALSO does this in HIS spare time for ‘fun’?
What a clueless fuckwit.
PS: Technically, the term is “regurgitate” not “ingest”.
i think you should stop ingesting software, forum poster ryan_kuba. not only it makes you sound like a creepy soulless corporate automaton it also seemingly impairs your reasoning skills so you can’t even understand the actual issue here - you serving your users obsolete code for no reason.
these people are so pampered it’s not even funny.
Also: https://git.tt-rss.org/fox/tt-rss/commit/5907409a84b83dd1ac19ec11ef18cab1000da486
note that this would still say unsupported.
That is really a twisted way to justify you refusing to acknowledge that you were serving your users stale software while asking money for it. Hiding behind fake politeness does not become you. Be better.