So how much are you willing to pay so that they can hire beta testers? In lieu of that, most of the extended testing is dependent on us - the user community. If you can’t live with that, don’t install updates very frequently, or switch to a commercial product and pay for that testing.
1 Like
But they already are (at least) two branches:
- bleeding edge → current latest version
- stable → wait a month or two, then install
No one is forcing anyone to install latest and greatest. You can test all you want, but you won’t find all bugs until version reaches general population.
I hope that noone expects for nabu casa guys to have ALL POSSIBLE devices, addons … (a few thousand of them, or even more) connected and running in their company and test them all before each version? First, it would cost a fortune, second, majority of addons (all HACS part) aren’t even theirs’s development, third, you’d need an army to do that.
Look this way: we, users, all test their latest versions, report bugs… and in return we can use HA for free.
1 Like
Not really sure… What if bug is introduced in, lets say, 2024.3.5… Does it mean that being the latest in 2024.3.x range it is LTS? Probably not, bug will be eventually fixed in 2024.4, but this version will introduce their own breaking changes and bugs (along with features, obviously). Developer will never release 2024.3.6 to fix outstanding bugs, but will focus on new releases. So to me rather all version are bleeding edge…
2 Likes
Bugs are more or less introduced in versions xxxx.yy.0, in later versions .1, .2, .3… in the same month only these bugs are corrected (as i said, more or less). So, one of the options is to update just before new monthly version comes out: you update to final 2024.4.x version when 2024.5.0 is released and you have your “stable” version (as stable as it can be).
Sure, sometimes a bug is more serious and can take time to correct it. But, in this case only solution is go back to a working version and stay there until that bug is resolved.
As already written a few times: when software without bugs will be written there will be no wars, no diseases, no poor people, no death… and we’ll all live forever. Ok, a software which only calculates 1+1=2 is perhaps an exception 
1 Like
I see an opportunity for NabuCasa to raise some funds by releasing an LTS version 
(but ofc it will require some dedication for support)
1 Like
I’d happily pay a higher subscription fee for an LTS version, a few devs to create a robust RBAC system and a dedicated QA department.
1 Like
Except that isn’t the issue. If I don’t update for a year, and a security patch comes out which needs an update, it really sucks to have to rewrite your entire configuration
newho. I need to unfollow this thread now…
2 Likes
I love Symfony’s versioning structure:
Notice:
- LTR versions which span for 4 years! That’s 3 years of bug fixes plus extra year of security fixes.
- Normal versions with new features come up about every 6 months.
- Normal versions support overlaps for a short time (to ease upgrade).
- LTRs support overlaps even longer.
- Semantic versioning! Only “big” version number can introduce backwards–incompatible changes (like 5 to 6). Upgrading smaller version number (5.2 to 5.3) is SAFE (only introduces new features). Upgrading smallest number is safe (like 5.2.4 to 5.2.8 – bugfixes).
- Yeah, this is also open source software!
For me, that’s state of the art approach. You know what and when to expect. You safetly keep using old LTR version for a long time and upgrade big, or make smaller incremental upgrades like once a year.
1 Like
That does look nice. But if I’m reading it right, they only release twice per year, not 12 times like HA. So the LTR that spans 4 years actually covers 8 releases. They also look like they have a funding model that involves certifications, backers and related commercial products. All things that theoretically HA could look at, of course…
Yep. It’s “slower” than HA’s release cycle –> but also this thread looks to me as a call for a bit “slower” development pace (quality over quantity ;)).
All of that I hope HA one day could achieve as well, of course! I wish for HA to be successful 
Symfony is a framework – it’s not an “end product” – it is something you build your software upon. It is important that you can rely on the “framework”, that you can easily update bugfixes, not necessarily need newest shiniest new features all the time.
And I feel HA is a bit like that as well.
Look, when I configure “my home” upon the “HA framework”, I don’t want to constantly maintain it. It’s ok to tweak it a bit from time to time, it’s nice you can do something new from time to time, but most of the time → you want it to “just work”.
And since it is a software, it needs updates: bugfixes, security fixes.
There needs to be a way to marry those two aspects: having “hot new stuff” and/or “just fixes”.
At this moment, we’re constantly at the “edge edition”. As was stated, you cannot just use 2023.5 for a year and come back in 2024 for an upgrade – that way you’d be missing a year of bug/security fixes. But also being “on the edge” exposes you to being a “beta-tester”.
There’s also issue with HA being monolitic (thousands of built-in “plugins” aka integrations) instead of just being a good dependency manager. It can’t be for now. You cannot develop all those integrations separately, without a good, stable base, while constantly introducing backwards-incompatible changes, without good versioning.
I don’t think you can compare Symfony to HA, sorry. They are totally different pieces of software, with a totally different focus. Where stability is the top priority of Symfony, one of HAs priority is to be up-to-date with what manufacturers bring to the market. HA depends on the update cycles of third party hardware, and it has to react, if something changes.
Symfony on the other hand is its own source. They decide when to bring something into their project, they don’t have to rely on third parties and what they do.
Taking this into account, I’d say every project has its own pace. It always depends on what it is used for, and how many components it has to unite.
But I’d say, the frequency isn’t that important anyway. HA has come a long way regarding updates and changes, and it is evolved over the years. The important thing is, how these updates are handled, and how (breaking) changes are handled.
That’s one of the reasons, why HA has won stability in recent years, there are now rules in place, on how to handle changes. I remember the times, where you needed to look into the release post, before you upgrade, because breaking changes where announced and made. That was a source to break things easily.
Nowadays every (breaking) change has to be announced in the log for months, to make people aware of changes. The way a breaking change is handled has changed to deprecate > announce > wait > do the change.
And let’s not forget one thing: for the vast majority of people the monthly updates from HA run smoothly and without any errors.
Let me ask you one thing: if you use Windows or Linux on your computer, do you ever think about the updates? And if not, why?
1 Like
Yep, it’s not apples to apples. But there are many common aspects, which can be helpful to notice and think about.
As I said, Symfony is a “framework”, HA is BOTH a “framework” (platform) and “end product” – at the same time. Of course, it’s different, but of there are commonalities as well
Kinda. Symfony “needs” to upgrade when PHP upgrades. Plus it also has to look at thousands of “bundles” and libraries one can use with Symfony (via “Composer” – the dependency manager).
Actually that was one of my points – Symfony (thanks to Composer and flexible – yet stable – versioning) does not have to “do everything”, can be split into smaller components, can offer thousands of “independent” libs to work with. Developed “independently”, instead of being a “monolith” like Ha is now.
You mentioned OSes: yeah, I see Windows both as an “end-product” and “framework” (platform) at the same time – just like HA. Imagine MS trying to micromanage everything like HA does 
I’m using Mac. I do think about updates. I update at least 6 months after new MacOS release. Sometimes later. And yet, I can remember MULTIPLE times personally, when Apple broke stuff I needed… Don’t get me started 
1 Like
I guess many people here would be interested in implementation of this FR
1 Like
I don’t believe that to be a true statement.
The FR has 24 replies, 142 views, and three votes. So, an eighth of the people replying voted for it and a fiftieth of those that read it voted for it.
I don’t believe either of those to be ‘many’.
And that with a forum of 229873 users
I think that separating of these two updates would only result in even more chaos. There are a lot of updates now, separating them would result in even more updates. Who really wants constantly to click “update” every day…?
2 Likes