What is still needed to move Home-Assistant to stable 1.0?
Are we wanting this to be “user friendly” before moving to 1.0?
We should take a little time to figure out what is needed/wanted to move this to 1.0. There is a reason we as Software Engineers/Developers use Semantic Versioning. This allows us to push updates that have different scopes. With all the breaking changes lately, we really should have been using the semver major. Users should be able to choose not to update with major breaking changes. Lovelace/User Auth should have been a Major version update.
Added components can be in minor. Or even we should think about moving components into a seperate versioning separate to the main Home-Assistant. We can set up a package manager and allow users to choose to stay with certain versions.
But before we do any of that we need a CLEAR goal that we are trying to hit to make this into 1.0. Honestly, I think the system is mostly stable enough for a 1.0 Alpha. Yes, it requires same manual configuration but it is mostly running without any crippling errors.
Yes, I joined the forum about this afternoon. I have been a user of ha for about 2 years. I joined, so I can help. If you don’t want to be helpful, please leave. As criticizing someone for asking questions and trying to help move things in a certain direction. If you disagree with what I posted about, please make an argument as to why you disagree. I would love to hear other points of view. I am willing to change my stance if someone makes a valid argument.
As of my background I have been a Software Engineer for 10+ years with even more time in the IT industry.
Yes 1.0 is just a number, but it does mean something in semantic versioning. A.B.C.D A is for major versions, this is breaking changes. B is for minor, aka things that add additional functionality without breaking things. Putty client may be .70, when was the last time you had to update it and redo most of your setup?
The reason I am bringing this up so that we have some direction on getting this to a stable place where others can decide if they want to lock down their a specific major version. Yes there will be times where you have to update major to get new features. If we have XYZ left to go, some of us can take a little time to get those there. At that point we have a “core” product that if we need to change a major functionality, or rewrite part of it, we update the Major.
Don’t get me wrong, the devs that have put their heart and soul into this have been awesome. They are doing great things. Some of the items I mentioned in my first post has already been started with the hass.io where things are actually in components that an individual can choose to install and update. They also do a great job at documenting. I love the fact that I can go into any release and see what was done and what the “breaking” items are. However, one should not have to worry about things breaking for minor releases. Since we have to worry about things breaking every release, we have to manually update or risk something in our HA not functioning when it auto updates.
Yes 1 is just a number. But numbers matter. Before you respond saying something negative, take a moment and think critically and try to be constructive. You don’t have to agree with me, and if you don’t tell me why. I am not on here to bash anyone and neither should anyone else. Most of us are adults, let us come together to help make a stronger product.
If there are no set plans or goals, we should start a conversation about setting these goals.
Perhaps watch this, it’s been live for about 3 months and @balloob gives a comprehensive overview of the state of HA and it’s the direction. Check out in particular this part about versioning to help answer your question.
Edit 2: I retracted some of my comments because the video did address the versioning.
Edit1: Sorry did not see that time code. Will update in a moment, let me watch that part.
Thank you for posting this video. It does give some good insight on the state of HA. I do like the general goals for HA itself.
I still believe we should move into a major.minor.patch.revision format, which I did not see anything mentioned about these. – I did miss it.
– Start update (I was a dumb dumb and did not see the timestamped portion. My bad all)
So I know there is a lot of things from that presentation to get things added. We should come together and decide what will make this “production ready”. If we can come up with a solid list, this will help make the change. They mentioned, not ever being able to make breaking changes. Software will always have breaking changes, but we was developers and engineers plan for those. That is why we increase major. It truely is a major change that requires more thought and planning for all. And if someone wants to push breaking changes, the release manager can choose to table that change for a major revision. Say 2 times a year. (I honestly don’t care if it is 2 or 20 times a year just as long as there is planning and thought behind it. Also thought if it enhances more than the headache of the things that break.). I am excited that with the new configurations and not having as many breaking changes.
– End update
The flat architecture could make this more difficult though. We would need to piece together what truely is the “core”. Then we would have to figure out how to make the other coreish pieces into dependencies that support the core and make it run. Some of this may have already been thought out and put in place. But once we have the we consider core, we can move into v1.
My question to everyone what pieces are need to have a full and complete core? Believe me, I know that software is never “complete” but if we set a milestone for what we want to call core, we can call that “complete”.
This could also help in release management. Reviewers can say if it breaks core or not. If it doesn’t, then we automate that release. Only times that break core should we (whoever has the job for release management) step in to do manual release which would increase major. Just a thought.
Well unless you’re one of the devs, it doesn’t really matter at all what YOU believe. Try taking part in conversations where you can make a difference (on discord) or in the architecture repos, pr’s etc and be prepared to roll up your sleeves and write some code to help make it happen.
@DavidFW1960 I totally agree with you! This is why I am working on getting the conversation started. Perhaps this is the wrong place, I figured “development” would be a good starting point. Since this is open source, I believe anyone who wants to provide (constructive) input should be able to do so. There are some out there that are not as technical but may have some excellent input on what is considered a production level product. I am willing to roll up my sleeves. This is just a starting point.
@sparkydave Yes, we already have that. But, in a true sense, minor should not be including breaking changes. The real issue is HA has been in a perpetual state of “beta” for many years now. This is why most of us are fine with breaking changes being pushed in these minor revisions. We need to discuss what it is going to take to get out of beta and into production state. I really do not think we are that far from doing this. But I want to see what others have to say.
Someone mentioned something about being “user friendly” meaning you don’t need to know how to code to have it running. Basically getting away from needing to edit the yaml files. The Lovelace release really brought this forward. There are other items that may still be needed before this is “production”.
So my question here is, what are some items that you have seen that make this more of a beta product? Not really talking about lacking features but things that make usability difficult for new and old time users.
Sorry david i have to strongly disagree with this opinion.
The user is a very important part of the software development. If you develop past your userbase, then for what are you developing?
That’s what he is trying to do. Getting mostly headwind back as response which is not really encouraging
@aidbish Thank you for the links. These will be a good place to talk about the actual details on getting things implemented that will take us to v1.0.
However, wanting to get information from users, I pose the same question: what are things that you have noticed in HA that make it not suitable (yet) for production? Meaning things that are difficult for a novice user to get up and running.
I think for HA to be truely production ready, all configuration would be done (or could be done) purely through the GUI. The addition of extra components should be via a ‘component store’ sort of thing where you would first enable a component (which would tell HA to create a default / basic config entry for that component) and then request the user to input the specifics of how they want that component set up (ie: type in IP address of a device, name, tick boxes for config parameters etc.)
I think they already have an idea on how to make it novice ready by having configs being done through the GUI, although they have to take into consideration those users who are happy to configure it by using yaml files etc. So finding that mix will be a challenge.
@sparkydave From a user standpoint, I would think this is the biggest issue/complaint. I would probably take it one step further and say anything that has to be inputted in a certain format, like json, has to go away by default, but still allow advance users the option.
