Oh good lord, you’re one of those who quotes line by line and can’t maintain na conversation related to my original post. Yuck. Just write your answers in conversational format. I’m not posting code here… sheesh. Plus you use it to REMOVE my points so you don’t have to address them. Example: Rolling releases are just continuous patching taken to the extreme without proper testing timeframes. Quote that. Of course I know HA is doing the same thing, it’s all the rage these days… it’s not particularly compelling other than as a way to look busy. It provides no particular significant quality improvement over a slower and more careful release cycle. Never has.
(It hasn’t changed anything in the overall industry much and definitely didn’t reverse anything in well researched works like The Mythical Man Month, etc.)
As far as the whine that I haven’t done anything to “amke it better”, pffft… been doing open source since before linux was even a thing – and if you stick to my original post you’ll notice I’ve made no claim it must be fixed, I’ve said it’s weak architecture for embedded devices and Tas does it better… and we all have either one to choose from.
(If you want the hard truth, both need better tagging of security vs feature updates, and long term support type branches, but that wasn’t part of my analysis of how Tas handles updates vs the ESPHome integration compiling and compiling and compiling, to build the same binaries over and over… on the user’s box…)
As far as the web installer thing you mentioned, ahh I see – you use some newfangled web thing… most of us old Tas folk just grab one of these and go… takes about thirty seconds and can be hosted locally…as mentioned in my already working upgrade script.
https://ota.tasmota.com/tasmota/release/
However, I do know you aren’t “going on with your life” since that upgrade webpage isn’t closeable and doesn’t go into the background… hahaha… unless you’re triggering the upgrade event from developer tools… (Grin)…
If you were connecting to the Tasmota AP more than once in the lifespan of thje device, you didn’t understand how to send it commands via a simple URL request with curl. Sorry you missed out on that, it’s essentially an “API”. All of the config can be done without logging into them… shrug… not sure what all you missed…
Already covered the problem with deciding when to patch via release notes above, needs “security” tags. Couldn’t care less on embedded devices that there’s some new feature I’m not using in one of the two hundred resulting object files in ESPHome for some device I don’t have, but it’s a recompile anyway… it’s currently not even smart enough to not rebuild the binary if nothing changed… even though there’s oddly a “clean source tree” button kinda acting like that’s planned someday… if it wasn’t cleaned, it shouldn’t be rebuilding…
make && make install … vs … make clean && make && make install – you follow?
But no, projects shouldn’t ALL be doing this “read our breaking changes!” crap… it’s getting old. How about you stop breaking things and take the time to migrate things correctly vs break? End-users should not be reading release notes to trust automating security patching…
I’m glad you like wasting time clicking buttons… but I automate away security patching both at home and for a living… enjoying clicking to patch is a very hobbyist-centric point of view and something hobbyists like. I was “over it” being interesting to wacth something like twenty plus years ago… ha… it’s the wrong path. You don’t even want to bother the user with it in a properly “product-ized” system. That said I know HA is really mostly run by hobbyists who love watching it do things when they click… when they could be outside enjoying some sunshine or spending time with a loved one… the older you get the less interested you are in watching something compile… that’s stuff the CI/CD pipeline is supposed to do before it even gets sent out to the end user… grin!.. not even the devs should be watching that silliness… the pipeline will alert if errors…
I can’t think of a single pro dev dept that sat and watched things compile in the last decade-plus… making the end user watch it? Or using their machine’s resources to do it? Pfffft… no. We wouldn’t let that past the change control committee… no way… not even twenty years ago…
Anywhooo… it’s too bad you never realized Tas had all the scale tools built in. TasAdmin I believe it was called, wrapped all that stuff with buttons to push if you liked buttons… and watching it…
I just wrote a very very short shell script.
It’s been years, like six (?) since I’ve seen Tas lose setting data… and it hasn’t even stored that in the same flash area as the code for so long, I wonder what was really happening on yours… it didn’t really have access to it unless you somehow told it to wipe the entire flash… shrug… but I mention it because it’s another side topic that has little to do withj all of this compiling the integration is doing unnecessarily – back to the original post we are supposedly discussing – recompiling constantly when it’s not needed for a particular architecture or any actual code change, actually raises the chance something will get changed and error out, that was running fine… significantly if automated…
And this IS after all Home AUTOMATION, not Home “let’s sit and watch a compiler build things”, right? I’m not running home automation to be wowde by someone’s ability to dump a compiler log to my web browser, after all! Hahaha…
Cheers.
While in the past it could often happen that you have a sensor supported in one binary it lacked display support because that are in a different binary (a manual compilation of things is then necessary).
(zero) to change the status quo. Not even a feature request? Just ranting… the internet in the year 2024 
Last but not least local automation that are actually easy to do and are not some 