What about FE? Full Experience.
HAFE?
Taking this thought (and I am no branding expert) forward; how do you know a Ford Fiesta is smaller than a Ford Mondeo (UK) - you just do because of the branding and advertising. To use the analogy further, you know it is a Ford Fiesta or a Ford Mondeo.
That is what should be aimed for here - I am running Home Assistant <insert model here>. Why not use fruit or some other family of objects? Debian Buster - Debian Stretch. Or Unbuntu or Firefox they all use families of objects (although for versions I’ll admit). Metals is a poor choice as it implies a ‘mine is better than yours’ mentality.
What needs to be learnt is that the name doesn’t matter as much as the communication about what the name gives you (both pros and cons) - that is actually the beauty of the table. At the landing point of someone saying “I’d like this”, you then need to be very clear to explain the options - the different models, not jump straight in to “Here is your image”.
I think the option (model) you have taken to be front and center - so at the top of your web page it says Home Assistant Mango - that is the way to solve the confusion of ‘which version do I have’. If you ask a Ford owner what model they have, they’ll be able to tell you!
Warning: Rant follows.
I don’t think there’s a need for “marketing names” for install methods at all.
These should say what they are. Nothing else. Anything that requires a cheat sheet to find out what it is sucks.
Why would anyone want to look up the difference between a Home Assistant Melon vs a Home Assistant Fruit Salad?
Btw, I also abhor the lately rampant use of silly names in other products. I still have to look up things like “Stretch” or “Buster” for Debian where “Version 9” or “10” is fully sufficient. There’s absolutely no need for calling software products (that have a version anyway) fancy, idiotic, unmemorable marketing names. Just my 2¢, no offence.
3 Likes
Well I think all suggestions mentioned in this topic, would be my guess. Then run the poll for about 2-4 weeks and see what happens. Or if you want a bigger audience put a poll in the next HA update 
I have a great sympathy for this view BUT
Just observe how big businesses treat it (I’m not condoning merely making an observation)
We’ve on version 7, but we’re moving to version 8
We’re on version 8, are we now moving to version 9 - No the next version is 10 - Why ? - Well from here on out we’ll be naming it after the year - Oh, so 2010 ? - No, we’ll just call it 10 - Okay
We’re on version 10 is the next version 11 ? - No, we’ve decided to go to 2011 - What ? but you said … - Yeah I know …
We’re on 2013, next years will be 2014 - Well no, the competition launched an interim release and we don’t want to be seen lagging and calling it XV allows non synchronous, interim and new launches on (say) a 8 to 10 month basis.
Why have we jumped from XV to XXII ? - Well, the competition released their version XXI and we want to be seen as better than them
So I think the ‘fruit’ idea is a pretty good one, except no one wants to be a Lemon
A N D newbies would have to be following HA pretty closely to have any understanding what the release version number signifies and whether it’s relevant (hands up anyone who was even a ‘little’ surprised when we went from 0.99.x to 0.100.x I’m not sure why I was … but … )
The name has to be a nice, easy handle that someone new to the system can relate to. The numbers don’t matter. If I ask you what OS you use you’ll just say Linux Mint (or whatever), - Oh that’s interesting, I’ll give that a try. (I’ll then go away and download the latest version)
1 Like
I completely agree! And also have to look up which Debian version is latest every time. (since it is so stable I hardly touch it ever)
The only reason I’ve read for not doing a non cryptic name is the length of it and the fact that people are going to go for the acronym of it, if it is too long. So the trick is to find something that is none cryptic and short so people use it as is. One word is usually key with this. Even a long one. I haven’t seen anybody butcher the word supervised yet. 
SoopRvZd
1 Like
This story sound vaguely familiar 
But anyway, I agree, but I also think @Moonbase59 didn’t mean to make version numbers out of the different ways of installations. I think he meant to make the naming as less cryptic as it can be.
Yeah that definitely fall in the category “butcher” a word. 
Yup. Exactly.
“Home Assistant Easy”
The post you linked to doesn’t contain what you claimed I said.
“You wanted a community decision”
I had simply expressed my opinion that one of the best suggestions from the discussion in the Architecture repo was to ask the community for its input. You then asked me questions about deadlines and next steps in the selection process like I was privy to this information. Except, I’m not an organizer of this process, only an observer.
The person who is in a better position to answer your questions, SeanM, has already replied to you.
Understood. So what is your proposal to identify the four different installation methods, and their relative differences, without employing a “cheat sheet”?
Currently, the four installation methods are called (with no accompanying feature table):
- Home Assistant
- Home Assistant Supervised
- Home Assistant Container
- Home Assistant Core
How can we improve that?
Well, so far I like your table from post 95 best, possibly with an added column “who is it for?” (see post 106). And possibly the explanation for “supervised”.
I think that would keep the “Home Assistant” name for the product itself, and clarify the possible installation methods just great while keeping a lot of names as they are. Short, concise, tabular.
For a newcomer, the table would be an enormous help. Wish I had had that.
Thinking about it … the table is a cheat sheet, isn’t it? 
Still I think the names are good (Supervised OS, Supervised, Coretainer/Container, Core). Or even—schematizing it even more—Supervised OS, Supervised Container, Core Container, Core).
Btw, since I haven’t used Windows for more than 8 years: Is there a specific installation method for Windows users? Or would that either be “Supervised OS” (full box, extra hardware) or “Core” (run it under Python in Windows)?
And what about the MacOS X users? Core? Homebrew?
I added a Skill Level column.
| Name | Skill Level | Supervisor | Add-ons | Snapshots | OS | Docker | Method |
|---|---|---|---|---|---|---|---|
| Hub | Novice | Yes | Yes | Yes | Yes | Yes | Disk image (1) |
| Hubian | Linux, Docker | Yes | Yes | Yes | No | Yes | Shell script (2) |
| Coretainer | Linux, Docker | No | No | No | No | Yes | Docker container (3) |
| Core | Linux | No | No | No | No | No | Python app (4) |
| Note | Description |
|---|---|
| 1 | Burn disk image, for your model of single-board computer, to SD card or as a Virtual Machine. |
| 2 | Execute shell script on an existing instance of Debian linux on a dedicated machine. |
| 3 | Install docker container in an existing docker environment. |
| 4 | Install python app, preferably in a virtual python environment. |
Installation is preferable on Linux; other operating systems can be mentioned in the documentation.
EDIT
-
I think the table makes it fairly clear that if one has no linux or docker skills, or no desire to learn or employ them, the optimal choice is the first installation method (Hub).
-
If you’re familiar with managing a linux system, but not docker, then you might want to use the second method (Hubian).
-
If you aren’t interested in the additional features offered by Hub/Hubian and have linux and docker skills, you have a choice of either Coretainer or Core.
2 Likes
Cheers. It’s getting forward.
Your edit: Exactly. That’s why the table is needed.
Does Hub (a node with a number of links that greatly exceeds the average) really fit? I immediately think of a network of HA instances when reading hub.
At this point in the discussion, I’m trying to establish a table that clarifies the features and intended audience for each installation method. I’m hoping that by seeing the table, it will inspire people to invent appropriate names.
What’s clear to me is that the first two are nearly identical in terms of available features (but not skills because the second one requires that you supply and manage the OS yourself). It’s this similarity that inspired me to choose names with a common theme.
I was partial to Supervised OS and Supervised to describe the first two methods. However, I have the impression the core team wants something ‘short and sweet’ and Supervised OS isn’t that. So I’ve migrated to Hub and Hubian to identify the first two methods.
As for the third and fourth methods, the only suggested change is to make Container into Coretainer to emphasize it is just Core in a docker container.
This is about naming, you are now entering some other discussion, which is already covered in the ADR. If you don’t know how Docker works, the last installation method to use would be a Supervised installation type. It requires extensive knowledge of Linux, Docker, but also networking in general. It is not just an installation script, as it requires additional maintenance to your OS after that.
Some examples include: configuring and picking Docker storage and logging drivers and keeping up with software and kernel requirements for the future.
The amount of knowledge needed and strict requirements is highly underestimated in general for Supervised. Sure, it works right after running an installation script. But if anything changes or comes up after that, one needs to be able to maintain it as well.
Tutorials/scripts are easy… after that… that is what counts.
1 Like