The pattern of release cycles is fairly predictable in the last 18 months:
All the time you have dev (bleeding edge - could break at any moment)
Towards the end of the month you have beta (should work but final fixes before released to the masses)
Then at the beginning of the month you have release, e.g. 2022.x.0.
This is usually followed with .1, .2, .3 over the next 1-2 weeks, due to some fairly significant issues that needed to be fixed.
The reality is that the beta period doesn’t tend to catch everything. That means when recommending HA to new users, I’m tempted to say “don’t install it in the first week of the month” to get the best experience. We could try to encourage more beta testers, but the reality now is what happens now.
But this means that approx 25% of all new users are having a potentially bad experience by installing a release that hasn’t got urgent fixes in it. This is not a criticism of anyone. I hold my hand up as even causing some of those bugs myself.
Actually the highest quality releases the project produces are the last ones in the month.
So here’s my suggestion (hopefully not too controversial!). What do people think about a ‘stable’ release user choice, where on the first day of a new month, they get the final release of the previous month. e.g. on 2022-12-01 they might get 2022.11.5.
Not sure if this has been discussed before. I realize that it might seem like creating yet another level of beta testing with even longer delays until problems were spotted.
But I think of “which version of HA I would recommend to Grandma”. It is probably not the one that goes live during the launch party.
I don’t think it’s too controversial; my installation schedule (for my production system) is typically about 3-4 weeks later than the official release schedule. In other words, my production system gets upgraded near the end of the month instead of at the beginning.
In contrast, my test system gets upgraded earlier so I can familiarize myself with the release’s new features and Breaking Changes.
FWIW, I used to install major releases promptly, and investigate any new problems and report issues, but I no longer have the luxury of time to do that.
I follow the same schedule as @123. I used to jump on each new release, but history has proven that to be very risky. I don’t have the luxury of a test environment, so it’s even more important that I wait for a stable release before I update Production.
One thing which could help would be to de-couple integration releases from the core. I’ve been burned a couple of times when core integrations I used were updated to add features I didn’t need, but the update broke functionality I was depending on. My only option was to back out the entire HA update and wait.
If I could have simply backed out the integration update, I’d have kept the new core version. And I’d feel a lot safer updating if I knew I could do that. I even wrote an FR to this effect, which is dying a slow death from lack of interest.
But further decoupling integrations would increase the combinations of things to test, and inevitably increase the chance that something didn’t get caught by tests.
I suppose users who know that they are installing something brand new will tolerate some bumps in the road as you both elude to.
My feeling is that users who don’t know and just happen to install 2022.x.0 by chance won’t know the risk in advance so are more likely to be disappointed.
That would be a possible drawback. But what I’m proposing is what’s already done with non-core integrations. It’s also how every smart phone, tablet and laptop works. The apps are updated independently of the OS. You can just let them auto-update, or decide when you’re ready to update each one.
Presumably testing would be done with the latest versions of everything. If something were missed in testing, as it is frequently now anyway, at least we wouldn’t have to back out the core update, just the offending integration.
@CaptTom I think you might be oversimplifying what happens when core integrations are updated. For example what if a new feature is added to an integration that requires a new constant in the core? Or if a change is made to one integration that has to be also made in all other integrations that use it? Currently all edits are made in one PR.
You would create a new problem of integrations not supporting old versions of the core etc and needing certain versions of each other. Basically you’d be asking the integration owners to deal with this complexity to enable users to attempt to keep running at risk.
I think that is more suited to an app environment where you are dealing with quite a stable API.
The benefit of them being coupled is that they are all tested together and the distribution containing a lot of integrations is known to be valid.
But with the sheer number of integrations I would not be surprised if we end up with that kind of model.