openHABian branch selection UI

@mstormi, continuing the discussion from DateTimeTrigger and timezones - #10 by scoobydrvr

Here’s a suggested version - the wordings here are open for discussion. @rlkoshak and anyone else who uses openHABian, we’d appreciate your feedback too. Note I personally don’t use and have never used openHABian, so I’m not familiar with it at all.

The goal here is to avoid confusion of openHABian “version” vs openHAB version.

Current/original version of the screen:

Suggested change:

I’ve also resized the dialog to adjust to the less amount of text.

IMO the branch names themselves could use a rename
stable → stable-2.x
openHAB3 → stable-3.x ← This is probably the #1 source of confusion, amongst many
main → HEAD

But yeah, I understand the headaches involved in changing the branch names around.

In the original screen, saying “to contain the very latest code for openHAB 3” really throws people off. They’d think you’d get the very latest version of openhab - which I’d interpret as 3.4.0-SNAPSHOT


I don’t have a lot of opinions on this. I do think renaming the menu options in the UI makes sense but I don’t think it’s super easy to actually rename the git branches. But this is a UI and the end users probably don’t need to know details about git.

I would not change main to HEAD though. I’d abstract this UI away from git entirely and call it something like testing or the like.

Abstracting the UI could potentially introduce a new source of confusion.

How? Do we really want to require users of openHABian to know and understand git concepts like branches, HEAD, and such? That seems a pretty heavy lift for something whose intended audience are people with little to no Linux knowledge/experience.

Thank you, everyone, for taking a look at this. I’ve been using OH since the 1.x days (as a passive hobby, not nearly as intensively as you all are) and I’m only just realizing the distinction here is the difference between openabian and openhab. Am I correct in saying that the version being selected in this menu is for the former and somewhat unrelated to the latter? To use a clunky analogy - the difference between a kernel and an operating system?
Perhaps the solution is in additional verbiage. For this particular menu, state something like “This selection only changes the version of openhabian and does not change the version of openhab. To change versions of OH, go to [location] in the main menu”.



A better one would be the difference between an operating system and a web browser. openHABian is the operating system. openHAB is an application, like a web browser. The two are developed and maintained independently. openHABian is a custom configured Raspberry Pi OS optimized to run openHAB and other related services.

It already says that though in your rewrite of the menu

Note: to select openHAB version, see the “openHAB Related” menu item.

Credit where it’s due - JimT did the rewrite, haha. That’s a fair point and maybe it just needs some additional language. Something to further drive home that what’s being changed is independent of OH as an application.

Agreed. However, the purpose of this particular screen though is exactly to switch git branch. Sugarcoating it and calling it “version” or something else, will only add to the confusion, especially since version is actually a different/separate thing as maintained in the github releases page and linked from openHAB’s main download page.

Thanks for the suggestion. What bothers me a bit though is that changing the openHABian branch may indeed(?) change openhab’s version between 2.x and 3.x so saying that this screen only changes the version of openHABian is also not accurate?

Nevertheless, I’ve updated the screen to this:

Note I can submit these changes as a PR if necessary.

1 Like

I still think requiring the target audience of openHABian to know these things is a stretch too far. Gioto branches are a developer’s thing. Not an end user’s thing. And I’m not suggesting not to mention the branch at all. But the first thing the end users see, the most prominent thing they see, should be the information that is meaningful to them to make the correct choice.

  • openHAB3: That’s pretty meaningful. If I want to run OH 3 I’d pick that.
  • main: This is meaningless to me (as the target audience). What’s a branch? “bleeding edge” sounds scary.
  • ‘stable’ : I like the sound of that. Oh, but it only runs OH 2. Does this mean the openHAB3 branch is not stable?
1 Like

I totally agree with what you said. That’s why I mentioned that the branch name itself should have had a different name. However changing that would cause issues for backwards compatibility.

“bleeding edge” sounds scary? Yes it should be scary. That’s the whole point. It’s the same as using openhab-snapshot.

So if we were to explore your idea further, how about this:

  • stable: recommended version that supports openHAB 3.x
  • latest: the latest version that supports openHAB 3.x, not as well tested
  • legacy: the old stable version that supports openHAB 2.x, no longer updated

This would mean it’s abstracting / hiding the underlying branch names, so you’d have to be in the know to know which branch they are actually called. This can cause a bit of confusion when they applied what they read here and used the same naming for the clonebranch= inside /etc/openhab.conf. But I guess if you are tinkering with conf files, you should know.

Why not

  • stable: recommended version that supports openHAB 3.x (openHAB3 branch)
  • latest: the latest version of openHABian, not well tested (main branch)
  • legacy: no longer updated, use for openHAB 2.x support (stable branch)

I didn’t say get rid of the branch names entirely. I just want to emphasize the info that users who don’t know git from a hole in the ground need to decide which to use more than technical stuff like the names of git branches. Put that stuff up front and put the technical details few will care about in the parens at the end.

Note, it should be understood that the latest version of openHABian supports OH 3, at least until OH 4 becomes a thing.

1 Like

gets my vote
great discussion guys big thumbs up

I see Jim already added, I think is important

Great feedback! Here’s a revised screenshot:

And this is what it will show when it encountered a custom branch:

I’ve also cleaned up the bash script/code to remove some duplications.


You actually didn’t mention how you ended up in this menu and that’s important, too.
If you choose a menu option like say 42 you are setting the context yourself and I’d expect you to remember that for at least some minutes…
Don’t get me wrong I don’t mind changing the menu wording but it may not be needed at all.

Yes please, thanks. Mind that so far label=branch, but now with abstracted labels you need to introduce a mapping to the proper branch name in the code.

Yes, that’s already in my code. Are you happy with the proposed screenshot?

This is a fair point as well. See the main menu below:

In my opinion, this is a clear distinction between openhabian and openhab, but the distinction between the two concepts isn’t clear from the outset. The openhabian documentation page doesn’t make this distinction terribly clear, either; there is just a short mention of changing between branches under “Can I switch openHAB 2 and 3 via openHABian branches?” that requires careful reading. I’m also willing to admit my ignorance as I don’t live in this project as others do. More than anything, I hope mine is a voice of the regular user. Feel free to tell me RTFM :slightly_smiling_face:

1 Like

@mstormi PR created

1 Like