It’s typically posted in the Blog
And linked off the update notice
It’s typically posted in the Blog
And linked off the update notice
This is part of the reason why I run Container versus HAOS. I can quickly change the image tag and flip between versions quickly and fairly safely. I also run MariaDB as a container and can quickly switch between “versions” as I need to.
So, if a release of HA includes a DB schema upgrade, I clone both the DB and HA containers and config folders and stash them in a backup. Then I pull the new HA version, let it upgrade the DB and test it. Should I need to roll back, it’s as simple as restoring my config directories, changing my docker-compose
file, doing another pull and getting back to where I was. I might lose a few hours or day of stats, but to me it feels a lot faster and safer. I’ve actually used this method on a test system of mine to answer questions about older versions of HA as well.
I do the same. I have never had to roll back far enough to a version with a older database schema. Do you know if HA will note a incompatible database structure and not start? Recovering my Postgresql database is the longest process of my backup/recovery workflow and I try to minimize doing recoveries of it.
Not really. What’s needed is more (beta) testers! HA is open source and it is virtually impossible to build test systems with every possible configurations/setups.
Reality proofs that most people just want stable software but not invest time of their own for testing beta/rc. This and the complexity/size of the projects leads to bugs in releases which then requires bug fix releases.
If you would have taking part in beta testing the roomba integration bug probably wouldn’t have shipped with stable.
Only roomba owners (like you!) can do this testing!
I’ve only had it happen to me once when I was still using sqlite3 as the DB engine and it spammed the log files with errors until it finally died. It was actually kinda funny to watch.
Just FYI, I’ve been REALLY tempted to leverage AWS Aurora as my DB engine eventually, especially with their blue/green deployment model.
File based backup/restores are usually pretty quick on a quality SSD (I only use NVME drives in my servers and 2.5" SSDs for longer term storage on my NAS). I can usually restore 40gb+ in less than 10 minutes (often MUCH faster than that). If I’m pulling from my NAS’s storage, it might take ~15-20 minutes MAX.
True, but that’s just the major release, not the smaller updates, and they don’t mention the OS updates at all.
Major updates have extensive release notes with a section for breaking changes. Every minor update links to the release notes, which then also holds a description of the fixes in that minor update. HAOS updates have links to notes too. I read them every time. What else could they possibly do?
You could have all the beta testers in the world and it still wouldn’t mean issues wouldn’t still find a way to make it into a release. Please read my reply for a full explanation, based on real-world experience.
Even if you had way more people testing, these are volunteers with a varying amount of time available to test. Most of them would not think to try reinstalling the integration from scratch, going through all the config options and monitoring for stability each time any code potentially affecting their integration gets merged to beta.
Update cycle has been brought up since the first day of this software. It was even more fun when it was updated every two weeks. So many breaking changes sometimes, but it’s what the people want.
See #19 above:
“I think it would be nice if the forums here had an official Releases category where there would be a post every time there was an update to the core and to the OS. That would give a dedicated place to look to see if any issues had come up.”
I want to read everyone’s reactions to the updates, each one separately, and not just release notes.
I concede that this is important to me, but apparently to no one else!
And In the Pace of New Users Joining, we will have tons of the same Topics/Questions every Month( Day after Day) As this is not a Release related phenomenon … No im not really laughing
Right but many People Don’t / Won’t use this “Category” only anyways, likewise as they Post “issues” related to 3rd Parts integrations etc in the Official Release Blog, instead of the 3rd parts Official Community Page or Github , And many don’t use the Search function Either, before they Post or Open a New Topic( Which there are bunch of duplicates/Similar of )
Well, you might not like this: if you make these kind of comments, you only prove that you’re not aware of the information that is out there.
I’m a little over 4y into HA, I have always installed every major release quite immediately and since the new release cycle, even the same day.
Sometimes it was necessary to install the interim updates to fix a minor thing and as stated by my fellow HA users: reading the release notes and breaking changes can help a lot.
My system has been rock solid with a few minor hiccups.
Your remark about being a beta tester: is there any software that has no bugs?
On top of that: are aware about the numerous number of integrations, number of supported platforms and ways of installation?
In my opinion, the devs are making one hell of a FREE product! (thanks guys)
Meaningless. All software will eventually have bugs. In the early days of this product the object was to literally add any integration that released an API. Feature creep is a real thing. It was insane what would break, just because.
I think the issue here is that breaking changes creep in when they don’t really need to. Software that works one day and breaks everything the next when a feature is added is super frustrating. That’s why more users than you’d think get a working system up and running and never update unless its absolutely necessary.
And there’s nothing wrong with that, if you have a “closed” system - you have what you have and you don’t change anything, you don’t add anything… you just use your system and it’s rock solid - in this case why update?
Some of my esphome devices has quite old FW (even over a year), since i don’t update if i don’t change something in the module. That’s why first thing i do on a new esphome module is disable firmware version sensor to eliminate annoying messages.
But, since some of us constantly change, add, replace, test… in this case keeping up the pace is the only option. And sometimes we can hardly wait for the next update
That is why it is important to read the release notes…
Some updates are just features, but every now and then there are also security updates, which could be important (especially when your system is exposed to the internet)
Nothing is meaningless. Every situation has meaning to someone.
Some want completely stable. Some want to play with breaking changes.
Everyone needs to understand and decide when to update their systems. That is really all there is to it.
Then there needs to be 2 branches. Bleeding edge and stable. Ideally there should be a third for a LTS.
Playing with breaking changes is a horrible mantra. If you want to play with breaking changes, download the beta.
Releases should always be as stable as they can.
WOW, that’s a term I wanted to hear