Hi everyone, my name is Jacky and I’m an ICT management student and it’s up to me to solve some issues from a ‘customer’.
The questions;
How are updates organized within openHAB?
How are updates organized within openHAB?
How often are these performed and is this just as much as the home automation platform Home Assistant?
How are these updates performed?
I couldn’t find any topics about updates. Thank you in advance!
I guess, you’re right with regard, that there’s no “non-developer” explanation on updates. [1]
To summarize your question:
Apart from “stable” branch, there’s nightly builds (calles “snapshots”) for developers and Milestone-Builds, which are “kind of” stable, but mostly untested and “on own risk” for end users “testing” openHAB.
If you’re using a Raspberry Pi, you should use openHABian, which takes care of all that “internals” for you, there’s a menu for that (sudo openhabian-config), which you can access via SSH and chose your version (stable, Milestone, Snapshot) and it’ll update for you via that menu.
If for some reason you don’t use the ready-built openHABian, you can either use “apt-get update” functionality, but then you should know, how the package manager works with regards on chosing the branches as explained above.
[1] if there’s a easily accessible explanation apart from Download openHAB | openHAB, please feel free to prove me wrong! 
No, twice a year, June and December.
rrrright, sorry. Updated my text above.
Please be more precise in asking/explaining the background of your question, it is unclear.
What do you understand by an “update” ? A new code version to contain new features ? A patch that brings fixes but does not change anything about functions ?
Codebase is organized like those guys responded but usually the term “update” applies to a (running) system, not a software.
In openHAB, It’s all up to you, the owner, how often and when you update your system. There’s no automatism by default. This is by design to keep running systems as stable as possible which I believe is a difference to how HomeAssistant is organized.
Then again, while this is true for the core code, you can have OH update all of its addons on every start from the internet.
I want to elaborate a little on this in regards to testing.
Snapshots: these truly have limited testing. They include everything that has been merged up to the previous day. These versions are testing versions and are the most likely to include a regression. I’d consider these to be alpha releases. However, that doesn’t mean that no testing has been performed even on Snapshots. The developer(s) of the change obviously tested the change to the best of their ability. Their code was reviewed by at least one other developer. And there are unit tests that test for regressions across large portions of the code baseline. What hasn’t happened yet though is running the changes on live production systems across a wide variety of installations.
Milestone: Once a month, when there are no known major bugs a milestone or testing release is created. It is not true that no testing has occurred. There is up to a month’s worth of testing that has taken place on the changes that make up the milestone. But the amount of testing that has occurred depends on how close a codebase change occurred before the milestone so yes, a milestone is more likely to contain a regression than a release. But that doesn’t mean it’s untested. If Snapshots are alpha tests these are beta tests.
Release: Twice a year a new release is created. In general a release is really only just a little more than a Milestone. There will often be a short period (couple of weeks) when the baseline is frozen with only major bug fixes being allowed while the alpha and beta testers (i.e. those running Snapshot or Milestone versions) run the code. At the. end of that period, if there are no major regressions the milestone is set.
I always bristle when I see it said that the milestones or even the snapshots are untested. The amount of testing that has occurred for the snapshots and milestones is greatly underestimated and the amount of testing that occurs for a release is greatly overestimated.
I also bristle when I see the misuse of the term “stable”.
Any installation of OH that remains unchanged is stable. “stable” means unchanging. If I installed a snapshot version of OH at the beginning of the month, my OH instance has been stable since the beginning of the month. So yes, the OH release is more stable between releases because it only changes every six months. The snapshots are less stable because it changes up to once a day. But it only changes for you if you install the updates once a day. openHAB is as stable as the frequency in which you choose to update regardless of which version you install.*
The biggest difference between the snapshots, milestone, and release version of OH aside from how often they are released is how likely it is that when you install an upgrade there will be a regression (a regression is something that used to work but no longer works and it’s unexpected, sometimes called a bug). If you install the latest snapshot every day you are more likely to encounter a regression at some point than if you install a milestone once a month or a release twice a year. But if you don’t upgrade you won’t encounter any regressions caused by changes to the code at all.
However, the number of changes between one milestone to the next is much greater than the number of changes between one snapshot and the next. And the number of changes between one release to the next is much much greater than the number of changes between one milestone or one snapshot to the next. Therefore, one could argue that updating to the latest Snapshot every day is more stable than upgrading from 3.0 to 3.1 because the amount of changes going from one Snapshot to the next is incredibly small compared to the number of changes between 3.0 and 3.1. You are more likely to have to change something or fix something in your config when you upgrade between releases than when you are on milestones or snapshots. And the number of things you need to fix is going to be greater than between the milestones and snapshots. This is because not all changes to the openHAB code that forces you to change your configuration are regressions. Often there are deliberately implemented features and breaking changes. The longer you wait between upgrades, regardless of the version, the more of these features and breaking changes you’ll have to deal with when you upgrade.
So, if you really want a stable system, install it, seal it in concrete and never touch it again. Given that’s not reasonable your system is only as stable as you choose to upgrade it. But beware, the more stable your system is between updates, the more likely it will break and the more things you’ll have to fix when you finally do have to upgrade. In my experience, those who update early and often have a much easier time than those who make huge leaps between versions. In the ways that matter, i.e. their home automation has minimal down time, updating frequently leads to a better overall experience.
As usual, @rlkoshak is on point.
I only beg to differ in one point: Stable.
usually in Software development “stable” means tested and just that: stable! - at least, that’s what the term is supposed to mean. Nowadays more and more systems appear to be smoke tested and gone right into production…
what also comes into the equation is, that most software has a bunch of automated testing. I don’t know how this is the case with openHAB, but I guess, there’s some CI strategy around…
So, my understanding is:
So, in my world “stable” is the most accurate description of a piece of software, that you could have - the more so in a open source community.
just my 2 cents.
Maybe it’s a difference between the common meaning of the word and the technical meaning of the word. This article is relevant: https://bitdepth.thomasrutter.com/2010/04/02/stable-vs-stable-what-stable-means-in-software/
So do we mean stable is "unchanging " or do we mean “runs without falling over”? Far too often the people who use the word don’t even know what they themselves mean and try to have it both ways. That’s the part that irks me.
But I’ve never seen the term “stable” to mean tested. If that’s what it means then no version of OH can be called stable because the difference in the amount of testing performed between a milestone and a release is miniscule. So either both milestones and release are stable or neither are.
Honestly, that’s not too far from how OH testing goes, honestly. There is no separate testing team exploring every little nook and cranny of OH’s code to look for bugs. OH is “smoke tested” through the unit tests , released and then we wait for people to complain.
I don’t know the extent of the code coverage but I do know that just about every class in OH core has a corresponding unit test. I’ve not looked to see if there are any automated integration tests but wouldn’t be surprised if there are some.
I think you underestimate how many and how diverse the users are who run on the milestones.
Almost. don’t forget that there is usually no M6 release. All the changes made between 3.x M5 and 3.x+1 are tested no more than a regular milestone release. Even in a release there will be some code that has only been in the wild for a couple weeks (depending on how long the code freeze before the release is).
There is no point where after the last milestone development stops except for bug fixes and then that last milestone becomes the release. Literally, the only testing period for a release is that two week code freeze and even that is just a code freeze on new features since bug fixes will still continue. Given that, the difference between a milestone and a release in terms of testing is so minuscule as to not exist. In short, the difference is that a release has no new features added in the two weeks before it’s release but it will include bug fixes up to the day before it’s released where a milestone will include bug fixes and new features up to the day before it’s released.
That’s why I encourage running on the OH milestones. In practice, the only difference is that it’s going to be a much bigger job to upgrade between releases and between milestones. The amount of testing that went into each is pretty much the same.
Stable is only called that because it doesn’t change for six months. It has nothing to do with the amount of testing it has undergone.
Is there any place to see what is implemented in a specific snapshot? Or is there some way I am missing to see the latest accepted/approved PR in GitHUB?
There is no curated list. In Github “issues” you can filter on PRs and on “is:closed”.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.