What is up with all these breaking changes?

[mateuszdrab]

I’m pretty much on the same boat.
Before upgrading, I have to backup the config and the database. Then I have to list breaking changes between my version and new version and then apply them all to the config, restart in my dev instance to test and then finally approve my pipeline to push the current release into production (I have a docker build pipeline around hass). The amount of breaking changes means I can’t have an auto update process as hass is a critical part of my daily life as it automates everything around me.
This is why upgrading is more of a project and I usually upgrade every few releases. I was on 52 -> 65 -> 81 -> 88.
I’m planning on staying with 88 until permission system is ready, in the meantime I have to try to migrate to lovelace but atm I use the old states UI and I still use api key. The only time I’ll move to the users is when LDAP can be used. I’ve written myself an with provider for that, but it’s of no use to me when permissions are not there.

Other than that. HASS updates are a mess.
Mostly because hass is being restructured to feature capabilities that it should have had from the beginning. However, I think they should just hold on from releasing new versions with new features every 2 weeks and focus on releasing a massive update with those new features whilst maintaining existing components in normal releases. Similar to windows patch cycle and service packs. It feels like we’re all beta users.

[flamingm0e]

@mateuszdrab

It feels like we’re all beta users.

we ARE. Most of us fully understand this. It appears that there are a lot of people that think this is a complete and finished product. Those people probably need to be hit with the truth.

[stevemann (Stephen Mann (YAML-challenged))]

I belong to the “if it ain’t broke, don’t fix it” line of thinking. I upgrade very reluctantly- because upgrades of any Open Source software tends to always break something; we are all beta testers. I only upgrade if an upgrade provides a feature that I would like to use.

[nickrout]

@flamingm0e

we ARE. Most of us fully understand this.

And that’s what makes it great. Users are testers and we are all involved in development.

[SuctionSeat]

How easy is it to go back to older versions of HA?

I’ve had some issues with older devices logging in, nothing mentioned in breaking changes, and 0.87 seemed to work OK for me.

[123 (Taras)]

@flamingm0e

we ARE. Most of us fully understand this.

… and the ones that don’t understand post rants (frequently on, or shortly after, release day).

Clues for prospective Home Assistant users:

• sub-one release number (0.X)
• ‘breaking changes’ is a regular fixture of the release notes
• preponderance of “0.XX broke my whatever” posts on this forum
• two-week release cycle (it can take longer than that to analyze and correct a single bug)
• existing rants from other people who didn’t realize what they were buying into

caveat emptor!

[finity]

@stevemann

I only upgrade if an upgrade provides a feature that I would like to use.

Unfortunately that will only ever cause bigger potential problems since you then not only have to deal with the current breaking changes but every set of breaking changes from then until now. It could be a big mess. It’s easier to deal with the breaking changes as they occur a bit at a time.

That aside, I’ll say it again…

If the breaking changes would be better documented and communicated to the users then most of the problems would be minimized if not almost eliminated.

The typical…

“Hey, there was a breaking change for X. See the docs. But we aren’t going to indicate what is changed in the docs so you will have to spend an hour reading through them to try to figure out where we hid the “easter egg”, Then when that fails (because we usually hide it pretty darn good!) you’ll likely have to give up on that. Then you’ll need to go to the forum and post on there begging for help, as you sit and stare at the screen waiting for a reply that may never come, hoping that eventually somebody might be able to answer your question, and then hope that some people don’t treat you like your stupid because you “didn’t read the docs”. All of that so you’ll know how to get your house back up and running again. Good Luck!”

…doesn’t usually do much good for peoples moods.

A more thorough documentation of changes would go a long way to alleviating any extra consternation caused by those inevitable breaking changes.

Luckily there are a lot of smart and helpful people on here.

[luma]

This topic keeps coming up and the answer is often the same: read the github pages and then you’ll have the opportunity to participate! This answer is patronizing and impractical. It’s the developer equivalent of the Vogon Galactic Hyperspace Planning Council.

Currently, there are 147 PRs in progress. We are asking all users to review each of 100+ changes currently in flight, every two weeks, full of technical details, to weigh in on the decisions being made. Home Assistant is used be a wide range of people, and I would strongly suspect that a majority of those people are not python developers.

The result is that the only people making the decisions about user-impacting issues are developers trying to solve a point problem, with (seemingly) nobody advocating for the overall user experience. For each developer addressing an individual problem, making a change which breaks their own configuration is no big deal. What’s not being considered is the fact that you are also breaking the installations of tens (hundreds?) of thousands of other people while doing so.

This approach also makes finding solutions to problems difficult for the user. Search the forums about a problem and you’re as likely to get advice which no longer works due to subsequent breaking changes as you are to land upon a currently-functioning solution.

Meanwhile, there are 1000+ documented bugs currently on the issue tracker. These are real problems being experienced by real users, and instead what we get every two weeks is Yet Another YAML Keyword Change for dubious benefit and which renders your installation completely unusable.

One could simply stop updating, but then you create the problem where when you eventually MUST update, you now have months or years worth of compounding breaking changes to deal with. Even for an experienced user this process is a nightmare, because those breaking changes are documented in a series of blog posts individually, and there is no roll-up document of “shit we decided to break for you” anywhere to be found.

This process is in desperate need of a user experience review board of some variety. Create LTSRs for normal users, and run the two-week release cycle as a beta program for developers to work with. Engage actual users (not just developers!) in decisions which result in breaking everybody’s install, and enforce guidelines on what sort of breaking changes will be allowed in each release, along with a clear path for migrating existing installations across several versions.

[anon43302295]

I think people would be less annoyed by breaking changes if they could see the actual benefits of them. Most of them recently seem to have been ‘just because’.

Tp-link being the example that’s specifically affected me from this release. Hasn’t been a bug/operational issue with tp-link switches for years, but it’s been subject to a breaking change and there is no benefit whatsoever to the end user of the changes (ie this hasn’t given any extra functionality at all).

[DavidFW1960 (David)]

@luma

Meanwhile, there are 1000+ documented bugs currently on the issue tracker.

1000 issues, not necessarily documented and many no doubt are user error…

@luma

The result is that the only people making the decisions about user-impacting issues are developers trying to solve a point problem,

Well also stuff changes because big picture and consistency for things that were not all that well thought out originally being corrected moving forward.

This is still beta software… this stuff should be expected really.

How long does it take to scan through the release notes looking for components you use to see if there is likely to be any impact and reading the release note for the change?

@luma

One could simply stop updating, but then you create the problem where when you eventually MUST update

Yes this is a bad idea for exactly the reasons you highlight…

@anon43302295

I think people would be less annoyed by breaking changes if they could see the actual benefits of them. Most of them recently seem to have been ‘just because’.

Sometimes we users don’t see the benefit immediately or the long term big picture. I don’t believe the devs deliberately do anything just because even if it seems like that in the short term for the user…

@anon43302295

Tp-link

Not sure what this change was but was it broken out into it’s own component from the switch platform? Might be some specific benefits to that down the track…

[awarecan (Jason Hu)]

@mateuszdrab

when LDAP can be used

FYI: it is released in 0.88 Authentication providers - Home Assistant

[petro]

A lot of changes have been happening to help back end development. Basically saves time and helps with organization for the developers. The unfortunate thing is that it then requires the configurations to be moved around.

[aidbish (Adrian)]

What breaking change was there to the tp-link in 88. i didnt see one and wasn’t affected with it

[anon43302295]

It’s in 89, text based config no longer possible.

[aidbish (Adrian)]

The PR i see is to add automatic discovery for TP-link devices which does benefit users and the one it references says you cant add the name to config and only that. is this a different PR your talking about

[anon43302295]

Haven’t a clue what PR, I’m too busy having a life to trawl through thousands of entries on several GitHub repos trying to work this nonsense out.

[aidbish (Adrian)]

well thats the one in .89 and i see it as benefit if its found automatically for users and the only downside is you cant change its name which you can do by using customise. yaml or by using the built in customiser

[nickrout]

What drugs are you on, I want some. Or maybe not.

There is no 0.89, are you wanting to moan about something that is not even released yet?

[anon43302295]

Maybe my eyes are playing up but I’m sure that’s 89.

I wasn’t moaning, just explaining why people get annoyed.

[stevemann (Stephen Mann (YAML-challenged))]

@DavidFW1960

One could simply stop updating, but then you create the problem where when you eventually MUST update

Yes this is a bad idea for exactly the reasons you highlight…

Still fits the “If it ain’t broke” model.
Look, I agree that I will eventually upgrade. For example, I will probably upgrade my hardware to a NUC or repurpose an old PC. I will just start with the latest version then start adding components.

I have been helped immensely by the more experienced users here, but once in a while, I get an undeserved RTFM reply.

@DavidFW1960

How long does it take to scan through the release notes looking for components you use to see if there is likely to be any impact and reading the release note for the change?

According to my (i) information page, I have 83 Loaded Components. So a cursory scan of those release notes would likely be at the very least, a few hours- assuming that I know what to be looking for and where. And I suspect that I am a light user- some of you undoubtedly have more than 83 loaded components.