What is up with all these breaking changes?

im not saying that there is no direction at all.

im saying that i have seen the direction change over the years. and that can be good too.
and i am saying that i know there is a long term goal, but that there is a lack off short term goal.
or actually middle term goal, because i noticed that there are a lot of short term goals (2 weeks to a month.)

but off course i can be very much mistaken.
can you tell me that there is a goal like:
if we adchieve that and that then we will release 1.0, and we want to adchieve that before some date?

Except that tool was broken when checking against 0.89.0. So much for QA testing.

what tool? the configuration checker addon?
did you let it run and check the log? It takes a few minutes to run…

so much for QA testing??? WTF??? I will guarantee that none of the people on beta even gave a second of thought to checking the addon… so you’ve raised an issue right or do you just choose to spread your ‘wisdom’ without helping report errors?

1 Like

Wow… Complain get flamed. Honest constructive feedback is rarely received well here.

Something needs to change to make hass more friendly. Either the addon (Check Home Assistant configuration) needs to be built in for a pre-upgrade check to see if anything in the current config will break. List those components so the user can then evaluate to proceed or not.

Either that or split updates into modules rather than one monolithic bundle, like a lot of other projects do. At a 1000+ platform it’s just not maintainable. Every upgrade means compromises. It doesn’t need to be that way.

3 Likes

Having the update pre-check if your config has any of the breaking changes in place and advise and abort would not be too bad.

We’d have a ton of community posts when a new version comes out that “How do I fix xxxxx?” that clearly is a result of not reading the blog; but at least it would not be taking systems down and a new level of urgency.

Yes, the configuration checker is broken. Here is a quote from the Release Notes comments/

colorlog is not part the core dependency, so that check_config script should not depend on it, I will submit a PR to fix it.

For now, you can change your installation script to pip3 install homeassistant colorlog to fix it temperately. Or if you like colorized log in your travis, you can keep it there.

from 0.89: Nissan Leaf, PlayStation 4, Point alarm control, Owlet baby monitor - #74 by awarecan

Alpha testers & devs are supposed to test first. The project reaches beta when it is “feature complete” Features are still being added. It was reported by somebody in that thread.

I have built something like this for myself now.
It checks if a new version has been released (Including rcs) and then check my config against the new version.
I get notifications when the validation fails.

I was thinking about making it a public project for others to be able to also have this.

1 Like

I usually get annoyed with ‘complaint’ threads because the complaints usually come from people who just use the software and don’t lift a finger to help. It’s a rather annoying cycle:

  1. Come to forums
  2. Complain
  3. Get all their stuff sorted out, usually provide no information on their fix
  4. Disappear
  5. Reappear 1 month later.
  6. Repeat step 1.

I’ve been here 3 years and it’s the same all the time. It gets old. There’s a complaint of the month thread every month: Security is bad!!! The docs are hard to follow!!! I GIVE UP!!!

5 Likes

The add-on isn’t a core function, and therefore needs to be tested by the add-on developer or people who use it. If beta testers don’t use the add-on, how would they know it’s broken?

You’re complaining about something that isn’t part of core Home Assistant. It’s an add-on.

If it was integrated it would probably reduce the number of these complaints.

Then suggest it as a feature request.

It is an add-on from the Hassio official Add-On Store.
Since Home Assistant is pushing the Hassio & HassOs installations and the use of said config checker to avoid breakage, yes, they should have tested & verified it.

I guess you don’t understand the Add-on system then.

You would be correct if it was in a community repo. It is in the official repo just like ssh & Samba,

It’s so weird. I have gone through all the issues here and I don’t see any that discuss the configurator breaking on a particular release.

Maybe the core devs don’t have time to sift through and test every possible add-on and expect beta testers to do that…you know, that whole community beta tester thing…

2 Likes

Problem found, PR submitted, problem solved. @anon34565116 not sure why you make such a big deal out of it.

4 Likes

It might be wise for those who do not want unintended breakage to skip the “.0” releases and wait for the “.1” patch, if possible. I may try that for a while, going forward.

This has been my method for over a year and a half.

2 Likes

This is my first version upgrade where I had some meaningful configuration to break.

This is not in any way a criticism of this method of updating because I do it exactly this way myself and have pretty much since the beginning so please take no offense but…

It seems there are three (or even four) different levels of testers - beta testers in the dev branch releases, post-beta testers (production testers?) in the official realease and post-post-beta testers (you, me and lots of others) who always wait until the later minor versions to be released that fixes all of the stuff that the early adopter production testers catch.

I’m thankful for the first two categories of testers since it “generally” allows me to do an eventual update that doesn’t break things in my set up or at least I know what to expect and how to fix it.

But I also know that puts me in the category of “not supporting the community”. But there are other ways of “support” that don’t necessarily involve testing the newest release so I’m OK with not doing that.

but again I’m also OK with those other testers (and me :wink:) coming here to “complain” that something broke or trying to understand why things are the way they are or making suggestions on how things can be better. Saying things like “we are in beta so why are you complaining about this free software” makes no sense from that perspective. How else is anyone who is involved in making this better from the coding/documentation side of things going to know that there is a problem if no one “complains” when something isn’t right. Being a bunch of “yes-men (or women)” doesn’t help anyone improve anything.

Isn’t this EXACTLY THE TIME to complain about the things that are wrong and then maybe offer suggested fixes (or not, too, because sometimes you don’t really know how to fix something. you just know “it ain’t right”.)?

I honestly don’t remember one thread where someone who is “complaining” about something makes a true derogatory remark about the developers. Most of the time it’s people being overly sensitive to any criticism at all taking offense where none was given and then the accusations of “you’re rude, abusive, ungrateful, whiny, etc” come out.

Maybe others need to take a step back from being offended by the “complaints”, try to take the “complaint” in the spirit that it was intended and realize that most of those people are “complaining” now so that you won’t have to later.

4 Likes