If I may share my opinion:
The problem I see with the versioning you propose is, that Home Assistant is shipped with batteries included. By which I mean, that all the individual components are part of the same package. If a component maintainer adds functionality, that could be part of version x.y.z. But if that feature would introduce a breaking change, then it would have to wait for x.y.z to be released. And what happens with bugs that are found and fixed? The required changes would end up in x.y.z.
The result would be, that as a component maintainer I would have to take care of 3 different branches (if that’s the correct terminology), where each one targets a different global HA version. Some changes might be relevant for all branches, some only for specific ones.
All in all that would cause a lot of headaches for the developers, and realistically they would end up just coding for the nightly branch. If issues arise, they’ll just ask users to use the nightly branch, because that’s the only one that’s including that latest changes.
Now that leads to another problem: I would like to run the stable version, but I want to use a component that provides a required feature only with a breaking change? I can’t mix stable x.y.z release with code from the x.y.z release. Or can I? And what version am I running then when I’m reporting an issue?
Those are some thought’s about problems that come along with how HA is shipped.
A possible solution would be roughly the same direction as they are going with custom components right now. Those are independent of the core (as long as they match the architecture of the core, see the change talked about in the 0.89 release). If all components would be distributed individually, each with their own version, then it would be possible to just ship a HA core with breaking changes only happening in x.y.z.
I don’t know if you are familiar with ioBroker. There it’s actually the case that they ship the core with whatever version, and the adapters (which can be compared to components in HA) all cann be installed and updated independently.
tl;dr
What you propose would - in my opinion - only work if all (or the majority) of the components were shipped like custom components are today (or at least soon). The downside though: even those custom components could rely on functionality only available in the nightly branch. So again, users of the stable branch wouldn’t be able to use them.
As a component maintainer, for the most part you would always be targeting stable. In the event that the next X.y.z contains new features that you want to utilize, you would make a copy of your stable branch then target the next version. At this point you would not “version” your component since this is just a feature branch. Make your changes in this branch for the feature you are implementing. Then this branch would sit waiting for the release. You would not do any other changes in this except for that singular feature you added. In the mean time, you make all minor and security update x.y.z in your stable branch pushing that to users. There would not be any merging into HA code as it is no longer part of it. Once the breaking change gets released, you would merge your feature back into your stable and push that to users. Let me know if I should expound on this more.
The component maintainers should never target nightly as this has a high probability of changing/breaking.
I think your proposed solution is very viable and this may be the direction the team is heading.
So to expound on my questions through this thread. Another item that is needed before we get to V1 is to separate out the components from core logic. (I know easier said than done). Maybe add something that can check current component versions and auto update them to your current running version. (Dependencies and package management). But I see this as something separate from the “add-ons”. Or maybe they could be the same? Thoughts?
If the next X.y.z did contain breaking changes. These would be relayed much as things are done now. The component maintainers would look to see what needs to be updated (this could happen before the release, maybe in a developer preview). The process would be exactly the same.
@speedmann This is a great start to what I was saying for the components. It seems to be heading in that direction. Great find! I will have to dig into this discussion a little further to see where everything is at.
Would the people who continue to say “if you want to help then you need to become a developer and write code” please stop that.
There is a very small percentage of the user base that are actually programmers (and that is becoming more and more by design). Of those programmers there are many who don’t know how to code in python, java, json, html or whatever other flavor of programming skills are required to contribute to HA development.
But many of those users may actually have ideas that will help improve things. Every time a user brings up the fact they don’t like or agree with something then the usual response is “if you don’t know how to code then sit down and shut up until you do” and acting like their input is basically useless until they can contribute code is pretty condescending to those users. And to add to that the way any of those users are expected to genuflect before the devs before they broach any disagreement is just ridiculous.
Another thought to keep in mind:
HA heavily relies on 3rd parties. Much of those being cloud-based with unofficial vendor support. As a result, breaking changes may not even be the necessity of changes in the code of a component, but a requirement to keep a component in line with the vendor-specific API.
Imagine this:
April 2nd 2019: HA 1.0.0 released.
April 5th 2019: Philips makes some changes resulting in a breaking change for HA.
April 7th 2019: HA 2.0.0 released.
May 13th 2019: Telegram makes some changes…
May 15th 2019: HA 3.0.0 released.
…
…
November 3rd 2019: HA 25.0.0 released.
I think you see what I’m getting at. The ecosystem HA operates in just comes with breaking changes outside of the scope of what HA itself is doing.
So essentially stripping the components out of the core would be the only solution I can imagine (as of now) that can handle this problem if HA doesn’t want to end up at version 369.0.0 in 5 years.
Yes this could be a problem. However, this would be component level. As core of HA would only house the functionality to load the third party components. This would not break HA but would break the component. One would hope these third party api’s are not breaking things enough where the component would be up to 200 major anytime soon…
A big downside of extracting components from the core could be the code-reviewing process. If all contributers just maintain their custom component, it might not actually be well integrated with the core of HA. I’m specifically thinking of the async core that HA has switched to. Even as a developer who has contributed several times need regular guidance on how to properly take care of all that async-stuff I just can’t wrap my head around. I wouldn’t even want to count how often I have heard “you can’t to IO on the event loop” or “make that function async”.
If component development would be outsourced, the sort of quality management we have today would be lost.
In a way we already do some of this with hass.io. Some of the process would have to change but for the most part things would remain the same. There would be an “official” components, ones that are actually written by HA team, or have recognize it as official, then you would have 3rd party components. One’s written by users and may not have gone through an official QA process. These would not be auto loaded.
Maybe not this way exactly but something fairly similar. More time may actually be spent on components than the “core”. I could see a select group working on adding additional features to the core product for others to utilize. But most people would spend time on creating new and better components.
I agree that I need to bring these ideas up with the other devs. However, I am still gathering facts and user inputs before I propose a path forward.
Currently I think we have some of an idea, and just today, others have brought some interesting facts to the table. For instance: @speedmann found a great article on github where some of them were discussing very similar ideas. Something that I will be looking further into. But for now, I rather have this thread going to get others input on what they think needs to happen. So far users have brought up some user functionality that is lacking (or being improved currently) and some have brought up more underlying things. Rushing just for the sake of change is not the right idea. Well thought out plans take time and to do that, one needs to gather information.
You are not using responses from this post as some form of commercial marketing tool. There’s quite a bit of this about in the open source community at the moment.
I’m always a little suspicious of the “c’mon bring it on” approach when soliciting opinion.
It’s important that people understand the open source community is not some form of guinea pig test bed for the next wannabe billionaire.
You have a very valid point. This stuff is just a hobby for me. I love the Open Source community. I do know that it can be a drag sometimes. I have published (smaller, much) things as open source. Some people are very grateful for the time and effort that was put into things while other just complain. You are going to get that anywhere you go.
My goal of this thread is to get viable ideas and help make them some true for others to use. In no way am I bashing anyone that has put many hours into this product. I just want to take my expertise and help move it forward.
And I do agree with you, I hate it when companies take advantage of the Open source community by making money on it and never giving anything back (time, money, helpful thoughts)
You can’t compare hassio addons to the components of HA. Those addons are entirely different applications that run in a sandbox and just are useful in conjuction with HA.
And regarding the components: that’s how it already is with the custom components. They are maintained by their developers and just that. Those are the ones unaffected by HA updates. And the components that are included in HA are the official ones. It’s just in their nature to break things occasionally.
I don’t keep track of all the changelogs. But I do believe, that most of the breaking changes are related to components, not the core.
i think if you are serious, just join in the convos with the devs on those channels, find out where they are struggling, what they are moving towards and potentially help with those whilst engaging them to assist to move forward. Canvassing requirements here and going to them with a big wish list or a way forward on how you can make it better may not be the best approach.
With that said, one could argue that if you are not using that particular component you don’t really have to worry about breaking changes.
But on the same note, if one is not using that component, what is updating giving them? There may be a component 3-4 versions later that they use but as of right now to get that one components updates, they have to update all versions (well they can skip and just update the latest, but this gets more complicated as you may have missed something in the changelogs)
Wouldn’t it be nicer to say I use XYZ component so just give me the updates for these?
I do agree that most breaking changes are from components, which means for the core we would not be moving it as much.
