I take a different a different approach to upgrades.
Upgrade early and Upgrade often
Backup before every update
Keep updates offline and for 1 year.
I do this for all my Linux servers and desktops.
Why? Before we devolve into a flame war, this is just my opinion and we know what opinion are like and everyone has one.
The response time for HA correcting problems is fast. It’s not like commercial software where the downtime will kill an organization. It is an inconvenience and while I do miss what the automations perform, HA is not mission critical. I can still turn on all my lights, operate my garage door, and unlock all of my door locks. My situation is not yours so your mileage will vary.
This philosophy may introduce new bugs, but it is also fixing old bugs. There will always be bugs so this increases my chances to minimize the number of bugs.
And most times (very nearly all) you won’t even need to restore a backup. Just rolling back to the previous version will restore any broken functionality.
My experience, unfortunately is a roll back is not always a simple solution for some of the issues. So the amount of time I end up problem solving in the past when updating drives me to avoid living on the bleeding edge. Particularly when the other half asks why the lights are not functioning or the heating has gone haywire.
I wish I could and investing in trying to build a test system that will allow me to participate in beta testing and be on the front line.
At work where reliability is VERY important we most always wait before updating unless our account support teams say a patch release is critical. Whenever they say that there is a security advisory a week or 2 later stating why it was important.
I am lazy but with my container setup, where everything is in one directory tree, I would do this:
Stop HA
Backup the config folder to a compressed tar file
Update to the new HA container.
Rolling back would be:
Stop HA.
Move the “new” config folder aside & restore from the backup file
Start the old HA container version.
That should work regardless of the issue.
I think it’s fair to say that given the many different kinds of hardware HA supports, the developers and contributors are doing a pretty awesome job. However, I think that it would be part of a software product such as HA to mature even more at some point in time, an that (in my opinion) would include a more “safe” release cycle. Note that this is not meant as critics to the developers - it’s in fact quite the opposite.
Thus, I would agree (as somebody else has written somewhere) that dot releases should only contain bug fixes (i.e., no dependency updates (except if necessary as part of a bug fix) and in particular no new features). This would hopefully allow users to choose between different update strategies involving different “risk levels”, from being an active beta tester to always installing the latest release to only installing the latest (and hopefully most stable) dot release. And experience shows that a product with a vast user base as HA appears to have will most likely have enough users of all kinds to still discover most bugs, even if some users decide to go for the “safest” release cycle.
Has an approach like this been discussed before within the HA community?
How do you accomplish that when product vendors are continually releasing new models to maximize their profits? They also periodically change their APIs, breaking ond software that is not made by them.
That was my understanding too but now I’m not 100% sure about that.
There was just a dot release that broke MQTT and the reports were that it was because a “new feature” (code refactoring or some such thing?) was done in that dot release.
Of course, that’s just hearsay so I could be wrong (again…)
But I’m not sure if that original “fix” was in the .0 release or not.
Looking thru all of the changes (searching for “MQTT”) nothing shows up for MQTT Debug until the .4 release. Then a fix for that new bug was in the .5 release.
If it wasn’t in the original and it was added after the .0 release then it counts as a new “fix” added later but not as a “fix” for a bug caused by the .0 release.
I think that was the point of the comment.
only bugfixes caused by the original .0 release should be included in later dot releases. And those dot releases shouldn’t include any new code even if it was a “fix” for something else.
We want people to read breaking changes (and I guess technically every single change since any change can introduce a bug and end up being “breaking” whether meant to be or not) but then we complicate things more by adding extra changes later that aren’t part of the original release requiring users to read the changes for every dot release as well.
It wasn’t a new feature nor a bug fix, it was code refactoring. Refactoring is a structural operation on code where you clean up, simplify, remove cruft and make the code easier to maintain. It’s an important regular maintenance thing, but it’s absolutely not a bug fix, regardless of what the author calls it in the release notes. In fact, since refactoring will often change the fundamental structure of the code (or parts thereof) without modifying its actual behavior, it can introduce a lot of bugs. Larger refactorings require a lot of testing and are absolutely not something you would do in a bugfix release. They are large code modifications and should only go into .0 releases.
In our company we consider the testing and QA workload required after a larger refactoring about equal or higher to that required after adding a new feature. This is especially true in a non-compiled language like Python.
I always thought it would be handy to have a single reference document of “bugs discovered,” in addition to the Breaking Changes document.
This would be a living document, where bugs are added (with links to the appropriate pages) to a list as they are discovered.
I was not aware at first that Breaking Changes doesn’t list all known breaking changes. It only lists intentional breaking changes planned into the release.
If a bug is discovered after release, it’s up to the user to go searching here, on Reddit, on GitHub, Facebook or wherever else someone might have mentioned it. It would be easier to jump on new releases if we could do a quick check of a list of all the known bugs.
The issue tracker is the list of known bugs, you can filter it per integration. On each integration page is a link that directs you to all known bugs for said integration.
IIRC this link is coming soon in the integration page in your home assistant as well.
Thanks, I did know about the issue tracker per integration, just wasn’t in the habit of checking each integration before updating. It’s not that much extra work, so I’ll do that from now on.
My sense is that there are often bugs which don’t fit neatly into any specific integration, which is probably why I didn’t think of doing this before. I can’t think of any off hand, so maybe just checking each integration is enough.
