Extra-safe HA update option with issue checks for "LTS-like" experience on regular prod release track

[chefdeit]

Describe your core improvement

For HA installations for clients / family / friends and other uses and situations, intended to be self-reliant for long periods of time, where improvements and fixes are relevant but there's a low appetite for risk, it would be great to create a more conservative HA core / OS / add-on auto-update option, whose checks create an LTS-like experience "long-term support" without a separate LTS release track.

The idea is to automate some pre-update process due diligence currently performed by hand, to accomplish this function of keeping reasonably up to date quite safely and with a reduced risk of breaking things.

Current limitations

Current releases are made 3-4 times a month, with certain things deprecated "say good bye to the following" and at times issues being discovered early in the month and addressed in a latter point release.

The "quasi-LTS track option" would seek to take advantage of these signals as well as reduce the update frequency.

Technical benefits

The idea is to enable only "LTS-grade" updates by configuring the following traits + signals that a HA instance can check and use as filters/conditions:

1. Only look at end-of-the-month point updates on this track (.3 ... .5 updates not .0 - whatever is there during the last week of the month, and even that release NOT immediately after its availability but 2-3 days later) for the core on this track. For HAOS and add-ons, also wait a certain number of days for any issues to be discovered, that this new process would query for.
2. Support the option to only upgrade once every 3 months or twice a year, except for critical bug fixes (see below).
3. Support the instance being able to check in Github or wherever else appropriate, if there are security or bug fixes relevant to its installed integrations / add-ons, besides core - which would be considered a signal to update that month vs waiting for the once a quarter or twice-a-year update cycle.
4. Support the instance being able to check if there's anything it's currently running that's deprecated or "we say goodbye to the following" in the new release, and issue a warning or error alert instead of proceeding to upgrade if so configured e.g scheduled unattended LTS updates.
5. Support the instance being able to check if there are any Github open issues / bugs tagging the new release relevant to its installed integrations / add-ons, besides core. Those should be visible also via warnings / notifications as well as on any interactive update screens, same as the previous point.

Additional context

Although it might be possible to implement many of these points via a custom automation and Github integration, it may be fragile due to the sheer number of moving pieces that can change under it, and wouldn't be able to target the update notification screens and logic, displaying info relevant to the current install in a consolidated and concise manner. Hence this feature request is to enable it as a part of core functionality.

[criterion67]

I fully support this approach!

[Particpant]

It might be better if the updater could do updates incrementally, either by letting the user manually select which intermediate update to take, or if it would recommend 'checkpoints', where the checkpoints would be determined by which enabled integrations the current H-A instance has that have 'breaking' changes. Knowing if the change is actually impactful for the instance would be out of scope, but something that could tell you "stop here, and read the next release's notes" would be enough to make catching up when behind a lot more manageable.

[jonm802]

tbh, i think the whole update process, hassos, supervisor and core needs rethinking, I have lost count the amount of times i have had to restore my hassos vm lately cause of issues after updates.

the amount of restarts is also beyond a joke, there was a commitment to reduce the restarts needed, now even cards want a restart, surely its feasible to reload a component, maybe a yaml file, dict file etc

Looking at 2025.8.1, couldn't some of these have just waited for 2025.9?
yes maybe a bit of structure

[chefdeit]

It might be better if the updater could do updates incrementally, either by letting the user manually select which intermediate update to take, or if it would recommend 'checkpoints'

The point of this feature request is "For HA installations for clients / family / friends and other uses and situations, intended to be self-reliant for long periods of time". I.e. HA being able to update unattended, for updates that fall under a certain risk threshold. ...Although some of the features can be useful in a manual mode (HA being able to gather all the risk signals for its update vs not to update decision, and presenting them for the user instead on one simple & clear screen).

Signals such as, any previously open issues being closed by the update vs new issues opened for it; whether it deprecates or sunsets any feature or device, in the context of what devices & integrations/addons the HA manages.