I appreciate how fast home assistant grows and how fast releases are provided. However it is frustrating that almost as soon as I install a release, there are patches. Can we have past versions available to update? I’m thinking something like the terminal release of each month available. So 2024.1.4 or whatever it was for that month would be available to update to after the release of 2024.2.0 is available. This way I can update my friends who are not as interested in the latest updates to a “stable” release with that months changes in it without having to do it every couple of weeks during the month.
I think this is the next step in making home assistant something the mass user market could embrace and that could be supported by home automation companies.
Yes. It’s currently possible via the command line:
ha core update --version 2024.1.4 --backup
If it’s source of frustration then I suggest you don’t install the initial release. Update near the end of the month rather than the beginning.
If you have followed the project’s evolution, governance, and management over the past 5 years (or longer), you would be led to conclude that achieving “mass market” appeal is likely to remain elusive. Anyway, that topic is grist for another mill.
Nobody is forcing you to update, you can keep it outdated for as long as you want. You can also downgrade to previous versions as @123 pointed out.
They could sit on the .0 release until beta testers worked out any issues and then do a public release, but most patches are addressing issues that users discovered in the .0 release so I’m all for them. Personally I don’t generally patch to .0 releases because lately they have seemed more problematic, but sometimes I do - it depends on what new goodies it has (like yesterdays that adds being able to update Zigbee firmware). Generally I wait until mid-late month after the gremlins are worked out.
Mass market is already here and they seem pretty happy with it. If I recall the latest numbers, over 300,000 people have Home Assistant installed, that’s no drop in the bucket.
First, I’m not asking that home assistant stop doing anything. I’m asking that they add an easily findable and installable download for end-of-month terminal releases.
What home assistant is doing is fine for my house. I do like you do, I upgrade mid to end of the month. I learned long ago to stay away from “.0” releases with any software package.
I have used home assistant for many years, from back before HAOS was even developed so I am very familiar with the way home assistant has progressed.
With home assistant Yellow, Green, Blue, Pink, etc, home assistant is moving away from the original techie, hacker core and into a more mainstream market. Constantly being told there are updates to be applied can be confusing for newer users who may not be as computer-literate as those of us who like to tinker with things. Having a simple monthly or even quarterly release gives them the install and forget it until the next month which the next layer of users may want.
While 300,000 people is not a small number, considering the worldwide install base as its potential audience, it really is a drop in the bucket.
The “terminal release” depends on how many patches were issued in a given month. Last month the final patch release was 2024.1.6 but this month it may be less (i e. less than 6 patches). The last patch release might happen early in the month or at the end. In other words, the last release isn’t known in advance and the patch release number varies from one month to another.
In addition, I doubt the development team is interested in changing their release numbering scheme in order to accommodate something like “2024.1.final”.
That sounds like this Feature Request:
I believe Taras has answered your question so you should mark it as the solution. If the timing is a problem, then simply update your friends on the first Wednesday of the month using the command line above using the last version provided the prior month. That would seem so solve all of your questions.
This is part of the challenge i see with the home assistant community in general. Outside of nabu casa there is a lack of vision in what home assistant could become.
Just because there is a convoluted way of doing something doesn’t mean the issue of wanting an easier way to do something is closed.
I guess ironically in a way your name sums it up. If it’s good enough it doesn’t have to be a complete solution.
I don’t mean that to sound as hash as it does. It just seems to be a theme developing around feature requests in general. It seems that work arounds are viewed as solutions to requests to implement the real functionality.
Yes please go ahead and close this. I am sure home assistant will get where i hope it is going to go. I just hope it doesn’t take another 7 years.
You’ve been a community member since 2016 so you should be very familiar with the fact that the majority of Feature Requests are never implemented and the few that are implemented are done by volunteers.
The project’s founder, and his employees at Nabu Casa, don’t appear to use Feature Requests for their project plans. Many features they implement are rarely picked from the Feature Requests section. The WTH event is basically a call for volunteers to contribute solutions for the community’s biggest pain points (often found in an existing FR).
Explaining how to accomplish something using existing methods is usually as close as one will get to fulfilling the FR. It’s not meant to “close” the FR but just offer an alternative while waiting for a volunteer to contribute their time to implement the FR (if ever).
For the record, I am not asking that you mark my post as the Solution. I recognize it’s not exactly what you want. However, based on the odds, I also recognize that it’s unlikely your FR will be implemented.
I think I see the idea here.
Current we have developer and stable release channels.
What could be was a delayed channel too, which is just the last patch of the month before released at the date of the current month .0 update.
Exactly!!!
So re-release the previous month’s final patch version under a different numbering system? Plus make it available in the UI as a choice between upgrading to the latest release or the previous month’s final patch release?
The more that is written about this, the less appealing it becomes from the aspect of ongoing maintenance. Plus the term “stable release” is misleading because we all know it may still contain bugs that are corrected in the following month’s release. That’s why when a bug is reported, one of the first things checked is if the user is running the latest release.
If they’re not, it’s suggested they upgrade. If they were on the so-called “stable” channel, they would need to switch to the “release” channel and they may require assistance to make the switch. Or they wait a month for the next “stable” release containing the bug fix.
All of this is avoided by simply upgrading at the appropriate time and/or learning how to use the command line.
@turboc
If you want to simplify this FR, make it ask for a UI version of
ha core update --version <your desired version goes here>
That’s likely to have a better chance of implementation than creating and maintaining a separate “stable” release channel.
Or, as an alternative, write yourself an extension that monitors the latest release and considers it a “stable” release if the minor version changes (i.e., 2024.1 to 2024.2) or if X days have passed since another release and have that show up in your notifications in the settings panel.
Like @123 mentions, feature requests here don’t necessarily mean that the devs use this as a checklist of what to do next, quite a few “feature requests” are requests for things that are already possible but the OP didn’t realize it and for that this topic serves an excellent purpose.
It is probably not a good idea.
I complained once about having to read the breaking changes for each minor release and was told that breaking changes only occur in the major release, but since then there have been many breaking changes in the minor releases too, so that just shows that the patch/update management is a big mess.
Until the internal update management in NabuCasa is sorted out it makes no sense to try to provide extra features for users.
You’d probably have better success asking for this at linuxserver.io or creating an automation yourself. (So that you publish last month’s latest docker image to ghcr.io/youruser/homeassistant:latest every month)
Can you list some of the alleged “many breaking changes” that have occurred in minor releases?
I will once I get back to my desktop in the next week. 
For anyone wondering where each release (major/minor/beta) is documented, it’s here:
I know it feels like things are more out of control than they are, but i think that is mainly because there isn’t any coordination with integrations through hacs or platforms like esp home.
It might be, but it was integrations inth core update then.
You might be wrong, or right, but no one will know for sure until you provide evidence next week.
I look forward to seeing the “many breaking changes”, in minor releases, that have made the release system “a big mess”.