Hi, I don’t have any actual numbers to support this statement but it seems like each release has quite a few additional updates each month to correct issues. Does this suggest new features are being released too quickly?
What do others think? For me, very few of the recent updates have much value as I don’t have energy sensors or power generation.
The Internet is filled with unsubstantiated comments …
It suggests the developers are working hard to correct errors and provide a quality product.
Home Assistant has always had this frenetic update pace. Actually faster than once a month for a while.
It also has a very small beta testing team that can’t cover the combinations of all integrations and install methods. So some dot point corrections will always be needed.
There’s more chance there will be something that interests you if the pace continues.
Personally I’ve enjoyed the improvements to the template engine, rest sensor improvements, energy dashboard, and lots of other little integration tweaks.
Well, this is still technically considered beta software. (we’re not at release level 1.x yet) so I guess being part of the beta test group is kind of a given. Personally, I’m enjoying the ride.
There will be no v1.0, we’ve moved to a date based versioning system.
There will never be a release 1.x, as you may have noticed the tags and release cycle changed a few months ago. Now it’s year.month.x, e.g. 2021.9.3
Doesn’t matter to me. Nobody’s being charged for this, so…
Also doesn’t matter to me, been using HA since 0.4x and for me it is out of “beta” for a long time already. My system runs stable without any restart required for months except for the monthly update.
Be careful what you wish for. I am speaking from experience,
I started with HA when there were releases every 2 weeks. At that time I thought the pace was too fast and the OZW integration did not meet my Z-Wave needs very well. HA and openHAB were both undergoing major transitions at that time but, with the assistance of their excellent Z-Wave developer, I moved to openHAB.
They state that they release stable versions every 6 months, Milestones every month, & snapshot builds daily. Both projects have one major developer who is BDFL. OH stable releases mean there are very few bugs patched and, in practice, developers rush to deploy features for the “stable” releases. They expect the users to write the documentation on using the product.
I started moving back to HA about six months ago in spite of the fact I was quite deeply involved with Z-Wave support for openHAB. In my opinion, the BDFL acts more like BOFH many times, not giving a high priority to user & developer needs unless they are in his close group of friends. Not too long ago I was told I needed to wait 3 or 4 months before I could use my newer products because they broke backward compatibility in a Milestone build. The first “stable” version I used was released with a trivial bug that was reported many months before release. It was subsequently fixed with a workaround because the BDFL would not update the core.
HA developers appear, to me, to have more freedom. I was initially skeptical about zwavejs but my experiences say it works quite well and has a larger developer community than the openHAB Z-Wave integration (1 volunteer developer). For me, this is a hobby so I am slowly moving back to HA.
Yo could move to openHAB to get a slower feature development cycle but you need to evaluate any trade offs first,
The developers are amazing. Many thanks to their effort and dedication. @jenx If you like slow release then change to a commercial system. I came from HomeSeer and when I changed, I never looked back. My system is stable and I have never had it go down and become unusable.
Z-wave_js is so much faster and reliable than HomeSeer was. Not badmouthing HomeSeer but it is my experience. My wife has also noticed that everything just works now and works fast. I have 89 z-wave devices and rely heavily on them for automations.
@jenx You always have the choice of not upgrading. That is the beauty of open source.
The forum support is so awesome that I will take the rapid updating and the risk that goes with it because I know if something bad happens, the fix is coming soon and the support is there to get me through it!
Best regards
I agree with the general sentiment in the replies.
I usually impatiently update on release. It doesn’t break.
I only read this thread because I’m currently in a holding pattern waiting for one breaking change in 8.x to be resolved. Yeah, it’s frustrating. I want to start playing with the energy stuff!
But honestly, this too shall pass. There are things I wish were done better (testing, communication, prioritizing fixes for breaking changes in core integrations, etc.) but I’m a long way from giving up on HA, or even complaining (too loudly.)
Developers, keep up the good work! To the rest of us: Keep your arms and legs inside the ride and hang on tight, 'cause we’re gonna go really REALLY fast!
Really? How those things relate?
BTW you cannot opt-out from updating supervisor.
I can see open source term starting to be buzzword here to justify any issues HA encounters. Doesn’t matter it makes sense or not.
Speaking about updates. I’m also happy to update everything early. I love to read changelogs and to play with new features. But only under condition old features remain untouched. And this is where HA fails to me: I’m on 2021.1.5 because every build brings some serious issues without guarantee those all are fixed in patches for major version.
I have to admit, bugs are something normal in software development. What is worrying me is number of bugs not related to changes listed in changelogs. Either those are missing there or there are issues in architecture of HA with too many indirect dependencies.
It must be something in this, because once a component meets the core, it cannot be being improved and deployed separately from official builds. Which is pity for multiple reasons. As for example NetAtmo, once added to core, almost immediately started to manifest serious issue making impossible to use it. It has been fixed after half a year (sic! when in HACS it was worked out on almost daily basis!). And at this point there is no way to update only this module. One have to update whole HA (introducing a lot of other issues to his installation)
IMO modularity (like HACS addons are) would help a lot in maintaining up-to-date modules allowing to provide kind of LTS version of HA.
A broken core integration can still be fixed and used as a custom component (it will override the core integration) while you are waiting for the official fix.
If you able to track branches/MR and find the ones you are after, if you want to extract code to create custom integration, if you agree with tracking changelog later to remove the custom integration when merged with core etc (incl possible data transitions etc)
I think we can agree it’s still workaround. I suppose you are getting fun with doing workarounds over workarounds. I’m not. To me it sounds the same as “write a fix yourself”.
IN general it’s not bad idea, seems an infrastructure is prepared for it. But its execution shouldn’t require skill and additional effort from an user. At the end in this thread we are discussing making the user’s life easier.
So we may back to this idea once the system will be able to cover it automatically.
Anyway mentioned modularity requires to be supported natively in order to improve quality of the HA (less bugs, quicker fixes delivery)
One way to slow the pace of updates/releases is be careful to not install “dot zero” major/minor releases. Wait for a few patch cycles until “dot three” or “dot four” release comes out, to avoid too many issues.
That being said, the single most important thing to do is READ THE RELEASE NOTES for breaking changes. Often, existing integrations will be significantly updated or even re-written, requiring configuration changes or manual update processes. It’s sometimes unavoidable.
in fact it doesn’t slow anything. It just shift update in time a few weeks forward. But still it ends up with monthly updates one way or another. Yeah I know I’m nitpicking.
What is more important, there is no policy that all bugs introduced in a major version are fixed untill its the last patch.
I’ll play Devil’s Advocate for a moment, although I don’t want to come across as a whiner. I’m just a dumb user, not part of the development team, and I greatly appreciate all the work that’s gone into HA. Having said that, here goes:
I’ll use my current situation as an example. I have three Honeywell thermostats. Without heat, my pipes will burst and everything else in the house is ruined. This is not just a hobby; I need to know their status when I’m away.
8.0 broke the Honeywell integration. Not sure why it was re-written; it was working fine before. Due to inadequate testing (the developer only had one thermostat) it didn’t work at all for any more than one thermostat in the home.
The developer jumped right in, and with help from other users managed to produce and test a fix. That fix found it’s way into one of the point releases. But after a while, another bug was found. If HA ran for 48+ hours without a reboot, the Honeywell server gave a rate-limiting error and stopped communicating with HA. Somewhere in the process of fixing that bug, users started reporting an inability to adjust the thermostat set temperature.
We’re at 9.6 now, and no end in sight. I can’t upgrade and take advantage of all the new features because this core component is still broken. The developer is doing their best and I appreciate all the effort.
To me, it’s a systematic failure. Why was a poorly-tested core component updated and rolled into the production release? Why is there STILL no reference to these THREE problems with a core component in the “breaking changes” list? Why is there no way for the average user to back out the change for this one failing component?
Again, nothing against any individual developer. Bugs will occur and fixes will be frustrating for users. But there are ways to mitigate the pain.
There is. You load the last known working version into the config/custom_components folder. Despite maxym’s bemoaning it’s not actually that difficult. I ran the depreciated BoM weather forecast scraper for far longer than I should have (a better version was released, though it is not yet in core) this way.
Because breaking changes are not a list of issues. They are a list of changes you must make to your config.
I had a somewhat less troublesome experience with a few different devices over the last two years:
a) Ecobee thermostats - I could never really determine what was happening. But upon installing an update release, I had to delete and re-create my integration on the Ecobee website. This happened two or three times. It was annoying, but easy enough to correct. It’s been quite stable since then.
b) Alarm Decoder security system interface - Completely MY FAULT for not reading the BREAKING CHANGES section of the release notes. Once I did that, I was off and running. In this case, the integration had been re-written and greatly improved, and required configuration steps to re-define the monitoring zones.
c) LG WebOS televisions - originally required completely manual configuration, and the breaking changes were definitely improvements. It required some minor changes to the wake_on_lan value and formatting.
Nothing entirely difficult, just ordinary changes, updates, and “growing pains”. It all comes with the product, free of charge. 