I’m liking this idea as a workaround. But i would like to see the folks at nabu do it as part of their release cycle.
Or ideally give a list of releases to upgrade to in the ui making it easier to downgrade if needed or stay one or two releases behind.
Think of it in a business support model. You have 100 clients or hopefully more around town. When a .0 release comes out a lot more breaks than what’s listed in the breaking changes which is why in the space of a month we see so many patch releases.
By the end of the month most of the accidental breaking changes have been worked out and we start over with the next release.
Trying to do that for all of your clients would be impossible or at least very expensive for them to pay me to do.
These are people that do not need to be on the cutting edge like most of us. They just need an appliance that works.
Giving the ability to easily move them to terminal month releases is a step toward making it easier to support that group of people.
Actually, supporting stable, LTS, etc. Release branches create quite a big hindrance as how to apply critical security patches to all those branches independently. It’s doable, but it makes code management harder. And in the project like that one I think it’s better that team does not waste time on supporting it.
Same goes with the downgrade option. Too much hindrance on a daily basis, to make changes backward compatible and keeping track of versions to which you can downgrade, and find hidden dependencies for this option to be reliable.
But enhancing the update dialog with a dropdown of available higher versions would be great, especially that in this thread I’ve learned that you can already update to a specific version with a CLI.
This would be helpful as currently if you miss the last version in the month, you need to wait for another one, or go to the console.
I could not find the ones I were affected by. Maybe they were not marked as breaking change.
I did a manual search and I have to say that HA has received more updates than I imagined in my mind. 
There are breaking changes though. Not many but one is enough to invalidate the premise that there are no breaking changes in minor updates and thereby require a check on every update, minor or major.
Release 2021.2.3 - February 11
Use oauthv3 for Tesla (@alandtse - #45766) (tesla docs) (breaking-change)
Release 2022.2.1 - February 3
Update frontend to 20220203.0 (@bramkragten - #65572) (frontend docs) (breaking-change)
Release 2023.2.1 - February 2
Fix disabled condition within an automation action (@karliemeads - #87213) (breaking-change)
Release 2023.3.1 - March 2
Update pyTibber to 0.27.0 (@toini - #86940) (tibber docs) (breaking-change)
Four in the past two years.
That’s the evidence for this statement?
If you review the PRs for the ones you posted, they fix problems in a manner that’s not backwards-compatible (i.e. breaking change). They were done out of necessity; the majority of breaking changes are relegated to major releases (with advance notice) as part of new functionality (as opposed to bug fixes). That’s why they occur so infrequently in patch releases.
The alternative is to not implement them in a patch release, leave the integration (or frontend) broken for a month, and then implement it in next month’s full release … all to satisfy your perception of what constitutes orderly patch/update management.
In defense of the developers. Undocumented breaking changes are typically called bugs. Lol
I would love to have a release I can install that is a “gold standard” instead of updating a … “production release” that gets updated with bug fixes the very next day.
Yea, I updated to 2024.8.1 yesterday. It seemed like it was actually stable. I cam in this morning 21 hours later and 2024.8.2 was out. LOL
For the most part updating is an option not requirement. Any release is stable unless a security fix or bug affecting your system is fixed. Everything else is busywork. This is true for all software.
That would be the final minor release (“patch release”) at the end of the month. For example 202X.XX.4.
The policy has been to have a major release on the first Wednesday of each month and minor releases occurred on an “as needed” basis. The new policy is for minor releases to occur each Friday. 2024.8.3 is due next Friday
tl;dr
If you want the most stable release of any version, use the one issued on the last Friday of the month.
I’m not asking for a work around. I’m asking for a feature. What if I’m out of town the last Friday now I can’t get back to the release when I come back the Thursday after the new release.
Lets think of the next iteration of home assistant. We can now buy home assistant on a small system all setup and ready to start adding things. Lets say I own a high scale apartment complex. I want to put a home assistant green in every apartment ( 200 of them ) so that my tenants can take advantage of home automation features to save money and warn me ahead of time that something is broken and I need to send maintenance to fix it. I need to update those 200 systems every quarter. That’s not going to be done in 7 days. Lets say that June’s release broke my smart air conditioners ( a chamberlain type situation but with my air conditioners ). The company is working on a fix with our devs, but it wasn’t ready in June. So I don’t want to install June’s release for everyone, I want to install May’s this time.
My point is as Home Assistant grows and gets out of the work of techies like most of use that enjoy tinkering with stuff, and into the world where installers setup systems for people who have no idea how to update anything. IMHO, we need to have solutions that support that evolution.
Same difference; everything that needs patching happens by month-end. The last patch release is the “stable release” (or at least the “mostly stable release”).
Stability is a result of testing and the beta period lasts just one week and relies on volunteers (as does everything else in this project). If there are few volunteers, a bug may not appear until the initial release is exposed to a broader audience (all users). By the end of the month, most bugs have been identified and corrected.
Has there ever been any indication from Paulus that this is the direction he wishes to take the project?
No but back when I first started with Home Assistant Everything was built around a RPI, there was no HA OS, no HA Blue, or Green, or any other color. Since that time, the system has been made easier to trouble shoot and maintain by having commercially available boxes ( Blue, Green, Etc ) and standard install routes. I’m just looking forward into the future at what I ( yes me personally ) believe is the next logical step for HA as it grows it’s commercial footprint.
One thing I have learned with HA is that it doesn’t sit still. New features are added many of which are aimed at making it easier for non-technical people to use it. I do not see any signs of that process and life force of Home Assistant slowing down.
If you are going to commercially exploit an open source system, then you’d need to provide an SLA to those customers. In order to guarantee the service you’d also need to employ one or more developers that you can call upon to fix stuff. This is because Nabu Casa does not (to my knowledge) sell SLAs. Asking NC or volunteers to fix things so you can fulfill your SLA is not an option. You cannot guarantee your customers a working system without it.
It would then make sense to have those developers contribute features required for providing professional services, such as the asked functionality to roll out the month end’s patch release out in a staged manner to customers, which saves you time and money on maintenance.
Exactly why I want to be able to install the last “stable” release that I know worked for my customers.
Which still guarantees nothing. If it has a bug, the next one will arrive a month later, without guarantee the bug is fixed. You are selling empty promises. And why would Nabu Casa or a volunteer, free of charge, build the tools you need to make money of it? You are allowed to do so, but there are no guarantees.
But that issue is between me and my customers. It’s easy for me to give a list of devices I know work. System supports Ge Smart Switches, GE Outlets, Honeywell T6 Zwave Thermostat, zooz power strips, etc. Any other devices installed by residents fall outside of this SLA and are the tenants responsibility to maintain". Then I personally (who installs the latest version every month and uses those devices) can determine which release I want to give out to my customers. But that’s a business management problem and not within the scope of this request to fix. This scope is simply to give me the ability to install specific past releases if I want preferably through the gui.
Hou can wait for it to happen, or invest in your business the way I suggested.
The first part, as said is there, the preferrable part is not.
Yea, I can wait for it to happen. But if I don’t put in the request, it never will happen. Maybe by requesting it, Paulus or someone with HA development skills will say “Hey, that’s a good idea, lets do it”. Maybe not. There are a lot of things I want, most of which I probably won’t ever get. That’s life.
Update specific version in GUI is good idea.
This has nothing to do with “stable” label. I would expect a gui to maybe pull a list of available install and you simply need to install latest version or last version for a given month. It is kindof a pain to randomly add text label to number ordered scheme for convenience.