edited by original poster, sorry for the disturbing
Indeed, you expect too much, especially from a non-commercial 100% volunteer driven project. But frankly it’s unreasonable even for commercial projects. I used to have to do all sorts of stuff every time I updated Graphana because it would break on almost every update. And that’s a commercial product with a company behind it. My Zabbix instance is currently broken becuase I blindly upgraded it last week and this too has a company backing it.
You should never blindly upgrade any service you depend upon. You should read the list of breaking changes before you upgrade. And you should set aside time to deal with those breaking changes.
There are no issues with rules running from two weeks ago that were not fixed before the release that I’m aware of. Can you point to the issue in GitHub?
Automatically??? Ouch.
That now is an irresponsibly risky concept/approach no commercial admin would ever dare to use. As Rich already responded: You should never blindly upgrade any service you depend upon.
Even more so as we (openHAB maintainers) have broadly announced that whenever there’s breaking changes, these are bundled and introduced in major version releases.
So while we of course try to keep those type of changes and their impact at a minimum, they are still what they are: unavoidable breaking changes.
To expect a major upgrade would not break anything in your auto-approach is naive.
Show me any other software of comparable complexity that does this job better than we do, no matter if commercial or open source.
edited by original poster, sorry for the disturbing
I use a cronjob to check whether openHAB can be upgraded. If so, I receive an email stating so. That way, I’m notified, and I can schedule a moment to take my time for the upgrade.
So Portainer can read Release Notes for you? Not using it, must be high tech stuff.
edited by original poster, sorry for the disturbing
Please note that if you want a stable system, never use the .0 version. I would suggest to wait for at least three minor version updates. That’s nothing new or specific to almost any software, be it CAD, nextcloud, Linux, Windows and so on.
If you want to use bleeding edge, that’s also fine, but then your risk is higher. Your choice.
I use a test system first before upgrading the REAL system.
If it fails on test then I don’t upgrade.
Sometimes the maintainers know of the problems and would fix it. But sometimes they only became aware of problems from reports from other users like yourself.
So please if there’s a problem, make it known. But be specific and detailed with the aim of clearly communicating the issue so that they can be identified and fixed.
Just don’t expect that there will never be a problem. Nothing is perfect.
The safest way for you if you don’t have the time or inclination to deal with changes is to pin your openhab version and not auto upgrade, since you now know that newer versions can break things.
I have the code to do this tucked away in a script. I might turn it into a rule template. I’ve been looking for new templates to write since the release.
No one is saying OH is perfect and there isn’t stuff it can do better. But your expectations to be able to let Portainer automatically upgrade software without your input and expect nothing to break are unreasonable. That’s not OH’s fault.
Won’t just subscribing to github’s release do the same thing?
This is from “Watch” dropdown:
I guess it’s not quite the same. If you’re on 5.0, you won’t care about 4.3.x releases.
Sure. I’m just thinking some may want an “upgrade available” switch or message to show on a sitemap or MainUI.
My cron job tells me about any updates on the server.
I have openhab on hold so I get an email to tell me of any upgrades and it will also show me if openhab has an upgrade.
Then I do a test system check and if it is OK then I have a script that un-holds openhab and runs the upgrade and then holds it again.
Yes I am paranoid 
edited by original poster, sorry for the disturbing
@bandit7311 : you give not a lot of info to help you. You just say some of your rules are no more working but we have no idea what bindings are involved and what rule engine you are using.
Anything interesting in logs that could help identifying a problem?
Every new major version is generally coming with few breaking changes that are clearly announced in the release notes. So before any update, you have to read them to know if you are concerned.
For example, there were breaking changes in MQTT home assistant binding, I don’t know if you are using it.
You would not. There’s absolutely no need to patch OH unless it provides a fix for a bug you’re affected by and thus are waiting for, or when that fixes some relevant security issue (then again, usually OH ain’t exposed to the inet so even that isn’t always needed. It doesn’t happen often anyway).
But to patch software without a need to is a broken concept in the first place.
And when you do, don’t have it done automatically but take care, read the release notes and decide for yourself first if you really have a need to update.
I’d suggest that the topics related to “auto update” of OH without looking at either the documentation or the logs be extracted into a separate post?
yes, here you are.