The monthly releases are the major release you’re looking for, with the point releases the “minor” ones.
Creating less regular major releases won’t work. The builds are already large enough to cause GitHub issues with the monthlies at times. A quarterly release won’t work.
I don’t think github would be able to handle a longer release cycle with how fast HA is developed. The current monthly releases are all around 1500 changes currently. Any longer duration would increate that number and github may not be able to handle it.
The best way to ensure a “mission critical” service works is to test it.
Get a RPi4 (RPi3b in a pinch for simpler configs) and use that as a “pre-production” HA test rig. Devices like Z-Wave and Zigbee can be difficult to fully replicate, but others like MQTT are easy.
The added benefit is if your main production hardware fails, you have a cold spare waiting.
There seems to be a relationship between this WTH (here is another similar request) and the monolith nature of HA core WTH, which seems to block this and possibly other improvements / optimizations.
That’s a devops problem, not user’s or HA problem. There are projects larger than HA and they are built somehow.
Here is sizable demand for a stable LTS branch of HA which can be used for months (and ideally years) without breaking changes/database upgrades/etc (and ideally reboots).
This is just not possible. How can you imagine all integartions especially (cloud based) and automation work in two HA instances without any types of locks and synchronization?
You can already do that. Nothing forces you to update every month.
Whether you upgrade monthly for the small bumps, or quarterly for larger bumps, the only thing that would change would be that you’d have to read one long list of breaking changes vs a few smaller ones.
Unless those people who want this are willing to step up and support “LTS” I doubt very much the devs would be interested - they’re spread thin enough as it is.
Running unsupported software is a bad idea in general, there are no security and bug fixes.
I’m familiar with the rolling release model, I’m using Arch on my PC, but I would never ever be using anything like Arch on a server, because that would be a nightmare to maintain.
In that sense HA is the same, yes, somebody wants bleeding edge and fixing their install every month, and that’s okay, but others (and would say the majority) want things just work and maybe spend a day or two to migrate between major releases once a year or so.
That’s something I think ppl don’t understand: HomeAssistant is a backend-like software – install once, keep it working in the background – shouldn’t have to be a “maintenance” focus like every month.
Some people recommend to just update it less often, but that’s ridiculous: updates contain new features but also bugfixes and security fixes. In the best scenario, those should be separate.
Hence: the LTS model would be SO MUCH better.
Release LTS version like once a year and maintain just bugfixes and security fixes till the next LTS release and a half. Anybody wanting brand new features, redesigns, “hot stuff” can install versions in between, but that’s clearly not something everybody needs.
Understandable. Same as creating WTH forum category as well 
Or not…
The problem isn’t that there are “new features” vs. bug fixes. This is the largest (officially in 2024) open-source project. Just getting a new version out every month is hard enough, let alone having to gate-keep new features out. If you look at VSCode, they are the same way, with their monthly releases and then bug fixes for the rest of the month before moving on.
But let’s get to the most important part of Home Assistant. It is an integration platform, and often, vendors break those connections, and project contributors stop having time to work on integrations or otherwise (RIP). An LTS version would try to gatekeep out updates from fixes, and that would just make everything worse.
What I will say might be a nice help is a release picker version like in HACS, where, let’s say, you need to update to 2024.11.3, but 2024.12.0 is out and has a breaking change. Now you can do it via the shell I get that but adding it as a feature is one less barrier to entry.
That’s actually not an issue:
services:
hass:
image: ghcr.io/home-assistant/home-assistant:2024.xx.yy
network_mode: host
volumes:
- <...>/config:/config
environment:
TZ: America/New_York
restart: always
you can put any version you want in the container.
The problem is when the monthly release is closed - there is no bugfixes, security fixes, nothing. It’s like Microsoft releases windows 11 and instantly win10 is abandoned and you have to upgrade within a month.
I mean, having it in the UI, I know you can run commands or call a service. For example, in HACS, you have the choice of selecting the Version in the dropdown.
You mean in HAOS? I have no idea, I don’t use it. But if you want this level of flexibility - go with containers.
Why not develop a “Stable” vs “Experimental” model. Stable having maybe quarterly updates and Experimental follow the current release cycle. Then Stable could be better aligned with a production environment, vs constant tinkering with updates, etc…
Again, it’s the support/development overhead.
Unless significantly more people actually step up to help the project it’s highly unlikely there’d be any ability to do that kind of approach.
I would just add that Home Assistant is MUCH more stable than it was 2 years ago. Whilst there are lists of breaking changes you’d be unlucky to be caught by lots of them (I run 69 integrations and have had no issues for at least half a year).
I usually wait until .1 is out and upgrade that just to be on the safe side.
Personally - I’d prefer all the integrations to move out to their own repo - still have core integrations but don’t necessarily tie them to core home assistant releases
Yes I understand that’s an issue, but the upside would be HA could then possibly have a paid version for those that don’t want to constantly do updates or want to implement in clients premises. The example I’m thinking of is TrueNAS which began it’s existance as FreeNAS and has now morphed into Core and Enterprise, with Core still being the free version.
I do have one idea, but it would not provide security updates. Which is not that good.
If there’s an option to select only quarterly updates. It will not add additional overhead on the development other that there’s a bit more focus on the quarterly releases to provide complete features and stability. The 8 other release months would be hidden.
That’s been discussed a few times. From memory (which is imperfect) it was put aside as it’s a massive piece of work, requiring re-designing and re-writing far too much to make it feel worthwhile.
Put in this WTH as an alternative. UI support to update incrementally, with suggested breakpoints for releases containing breaking changes for the currently installed/set up integrations. It might be easier to do a slow catch-up that way, skipping ahead to just before your next update that could require some more than usual effort.