There’s nothing released yet, he was just talking about possible future plans on an unofficial podcast. I don’t think release notes is the right place to speculate about future possibilities.
If you want a written version you can read through the architecture repo.
That’s fine. I’m sure it will be in the release notes when there’s a final product. I was just suggesting a place to hear the inside scoop, nothing most users need to know unless their interested to know what’s in the works, or suggesting new ideas that are already planned.
I have seen things in the forum mentioned that were in the podcast but should have been in the Release Notes. It seems many releases are prefaced or accompanied by a podcast discussing the release and adding additional information.
The Home Assistant podcast is a good companion piece for learning about Home Assistant.
I started with Home Assistant version 0.79 and, as preparation, listened to every podcast created prior to that release (but over a span of two weeks, not as a single ‘binge-listening’ session!) in order to get a handle on how Home Assistant has evolved. It jump-started my understanding of where Home Assistant has been, where it’s going, and who are its principal ‘movers and shakers’.
I recommend other users consider listening to a few episodes. They typically discuss the latest release and then interview either a user or a developer. The latest podcast’s guest is Pascal Vizeli, creator of hass.io and the second first employee at Nabu Casa. It was very educational, particularly his description of the technical challenges of breaking out components (an architectural goal mentioned here and elsewhere) but especially for Docker-based installations. It was an angle I had not considered and highlighted the deep technical complexity of what may superficially appear to be ‘easy’.
Bottom line, for those who find reading release notes and breaking changes too onerous, listen to the podcast and let Phil and Rohan explain (most of) them to you.
I agree that the Podcast is excellent. I have listened to them with great interest and they are a great supplement to the release notes.
But a podcast is audio and cannot accurately say what to search for and replace in my yaml files. It is the exact FROM and TO text I miss. Not a long explanation. Just 1-2 lines of text detailing the scope and then the exact changes I need to do when I upgrade. The FROM is important. With the last change of Google TTS as example I have 20 places in the YAML files that relates to tts and Google but it was really only one place I needed to change something and it was easy once I found the example somewhere in a forum post.
Simple “if you have this blabla, then change it to blabla”. I can see that the past days the documentation has improved significantly about this change but there are 3 references to the tts feature and two of them do not at all give the full picture. The last which is the generic tts component doc is the one that describes the service_name option that you can change define as to google_say and avoid updating google_say to google_translate_say many many places. This detail is missing in the release notes. This is a golden example where a simple example could have made it much simpler. Not a lot of time consuming to write bla bla. Just add the example config from and to. Easier to write. Easier to use.
I have to ask, if it’s all so easy, then you must’ve contributed a great deal to the documentation. Correct?
It’s a community project. Each contributor of code is asked to update the documentation. If you believe some topic’s documentation can be improved, contact the last person who updated it or grab the bull by the horns and update it yourself. How wonderful it is have that amount of freedom and so little bureaucracy.
Since we’re offering up opinions about what we find to be ludicrous, here’s mine:
People who get free, community-built software and then expect commercial-grade performance, documentation and support. When asked to help achieve that standard, because it’s community-built after all, they offer every possible excuse why they cannot help.
To anyone who identifies with this behavior, I ask that you imagine you are a member of a team sport. You are the member who has:
never scored a point
never assisted a team member to score a point
never even cheered your own team mates
The one thing you have done is complain why your team isn’t better.
@balloob
While I think NabuCasa is an awesome service, I personally don’t get much value out of it, as I don’t rely on Google Home integration that much, and am planning of eventually phasing out my Google Homes in favour of Mycroft or some other FOSS alternative.
I kept my subscription active as a way of supporting the cause.
With that said, is there a better or more efficient way to funnel my money to aide in the development of HA?
No, subscribing to Nabu Casa is the way to go. I don’t want to spend resources on maintaining multiple ways for people to support the development, it’s not worth it.
For the people in this thread that want better release notes, think parts of the documentation could be improved etc, these are all things that can be done without requiring any coding skills. Open source is not done by just people that do code and then also do the other pieces. You think you don’t have time to do X but you expect others to do it? Okay, in that case help fund the project, so we can hire someone to do that work. I can guarantee you that, when it’s possible, Nabu Casa’s next hire is not going to be a developer.
I think I have explained pretty clear in my pull request breaking changes section, if you click the link embedded in the breaking changes section of release notes.
I often hear this argument - and normally not by actual developers. My mission here is not put blame or negative critique but to give constructive ideas.
My point was that it is OK to do breaking changes. They are needed for the long term goals. If the developer puts a few extra lines in the release note - not time consuming text - but copy paste the before and after config lines from the developers own test setup in the release notes - then the negative impact is much less when upgrading.
Only the developer can write in a release note what he changes. After the release the rest of us can collaborate on making the documentation better but the initial change can only some from the people making the change.
I am very active in multiple open source projects and have run a few myself with more than 200 contributors. And documentation and release management has been my main contributions. Between 2004 and 2016 I was leading the Motion project that quite many of you use today (the engine below MotionEye) and I wrote all the documentation. Motion is now run by Mr Dave who has taken Motion to a new higher level.
I was release manager on Twiki and Foswiki (two large Perl based open source projects)
I am still a new user in the Home Assistant world but I will contribute to documentation and probably also other things. I am very impressed with the project and the community. My comment was meant a sharing of experience.
On both Motion and Foswiki we had some pretty large breaking change cycles and a lot of discussions and I was responsible for the release notes so I have some experience - both good and bad - to share. And I always valued feedback from the users. I think the worst thing you can do to open source developers is silence.
I read this article the other day and thought it’s dead on! A complaint should always be accompanied by a solution. If it doesn’t, then it’s probably best to keep to yourself. I’m not trying to direct this at any person in particular but following some of the conversation I thought I’d share.
The devs here are doing an awesome job! I’ve followed every release (with the odd exception when I’m out of town) and I can say the release notes are generally well written. Kudos to everyone involved in this project! Considering it’s open source and free, it’s pretty amazing. It does more than every consumer product out there today!
I second the post regarding Mycroft. Google and Amazon already have too much information and I really like the Open Source, Privacy and data independence concepts of Mycroft.
I’m rooting for a future Mycroft integration that would allow complete local voice control of all my devices connected to HASS. I came to the “Update” post to see if there was any mention of Mycroft but didn’t see any. I’m hopeful it will be in the future roadmap.
