Hi
I’m using OH for couple of years in 3 different locations. What I want is stable and reliable system. I don’t want to be forced to update everything and spending ours learning new config structures and other stuff.
I fed up all this happening over and over.
There are more beautiful thing in our life’s than fixing (again) some broken improvement of OH.
Ola
P.S.
Just today I updated my rpi4 (raspian) with innocent sudo apt get update & upgrade - ending up with some still crazy messages of JAVA - Don’t rely on some something you are not controlling - make it C++ ( And yes , I am a C++ developer)
If you find that you are really happy with what you have mark all openhab related packages even whatever java you use to stay on your current version and just update everything else.
As will all opensource project nothing is a guarantee see redhat scandal.
Here I don’t think it’s openhab fault probably apt gave you a list of packages to update and you accepted or used the -y Wich I get it but if the system is stable why the did you run the command ?
Running apt update && apt upgrade frequently is considered good practise among many debian users and not something you’d do only once your sys get’s unstable.
àpt mark hold pkgName is a possible solution after you realise you*re about to break your running sys with this upgrade unless you install a different java runtime first and this and that…
It was announced in the forum but: Not all users follow these announcements regularly nor is it reasonable to expect that they do.
It would be helpful to warn of a major upgrade which requires a different jre to run at all, so that the user gets a message about the options (install jre or apt mark hold) and then the upgrade stops.
I ran into the same situation and had to manually downgrade oh back to 3.4.2, a heads up at that point would have been very welcome.
I apt hold the openhab packages and don’t update until I read what is going to happen.
Then I test it before upgrading as well, just in case.
It is easier to do that than fix a running system.
I do backups everyday as well…
You may not be alone in your desire to keep your OH installation pegged at a certain version, several other users on this forum make it known that they leave a stable OH system running un-upgraded for years. However, the vast majority of users want, expect, and enjoy new features. If you are relying on a package in that manner it is not a big ask to expect you to understand the update cycle of the package and take steps. OHs update cycle has been consistent for many years now. If you were surprised by this update then, again, that is on you. No software package is going to stop updates because a minority of users are satisfied with a particular version.
Stable is the OH devs job and they do a great job of it. As a developer yourself, if you followed the run-up to a full release, you would, I think the pleased with the process, effort, and consideration that goes into stability. Reliability is your job. That is system level property, not a software package property. If you would like to off-load the reliability aspect to someone else as well, then that is doable, but you would need to be a customer of a commercial application, not a free (multi-site) user of an open source application.
This is an unusual experience. The majority of users do not report such interruptions with upgrades (except for major version changes with well documented breaking changes). If you really do experience issues with many upgrade, then this is much more likely a feature of your system and not something anyone here can attempt to avoid unless you report these issues. Maybe you have a reasonable setup that does just happen to have common conflicts on OH upgrades. That sounds like the sort of thing it would be useful for Devs to know about so that they can iron out the problem. As a developer yourself, you are aware that devs cannot work to fix issues they do not know exist.
I’d have to admit I have not looked into how the openhab repository were made, because I use docker and I use snapshot versions anyway, but I’m surprised that major version upgrades (e.g. 3.x to 4.x) happened automatically with apt upgrade. Is that really the case? If so, that is a design fault of the openhab distribution, and it should be changed.
I understand the frustration but clearly this an understanding issue.
Running apt update & upgrade will install the latest version of an application.
It will even show a message “the following packages will be updated: …”
In that case it was probably a switch from OH3 to OH4.
If you want a stable version you should pin the version as suggested.
No - it’s fine how it is. If I install a new version of an application and even get a message that the application will be upgraded it’s unjustified to complain if the new version breaks something.
I can always
select no and don’t do the upgrade
pin the version to the specific one I tested that works fine and then do the update
As far as I know openHABian pins the openHAB releases and obviously that’s what @Ola_G should have been using instead of a plain raspbian (in the openHABian menu is a button “Install OpenHAB 4” or something similar).
We should use a separate repository for each version or some similar mechanism, basically major version upgrades must never happen automatically with apt upgrade. It is meant only for bug fixes / patches.
I totally understand the OP’s frustration here and agree with his point.
@Benjy WDYT about the following proposal in regards to the openhab deb/rpm packaging:
Add packages with a specific major version number: openhab3, openhab4, and their related dependencies (openhab3-addons?)
Keep the current openhab which also allows people who want to keep the current behaviour as is.
This way, if someone wants to peg their openhab version to, say openhab4, they can just install the openhab4 and openhab4-addons packages, so when openhab5 gets released, they will stay on openhab4.
I’m not familiar with deb / rpm packaging, but after a quick research, it seems that this issue isn’t unique to openhab. Nevertheless, it is indeed an issue, IMO. In any case, I hope my suggestions above would provide a solution to this issue.
I am not familiar with this at all, but if necessary, let me know what I can do to help further.
Ideally, I would like to warn users of upcoming changes before the upgrade, this has been quite tricky to figure out in a way that is compatible with both apt and yum/dnf and in a way that is autonomous with openHAB’s build system.
Personally, I think that the Linux package repository was underprepared in a way for the number of breaking changes users went through during the upgrade from 3.x to 4.x. There are maintenance advantages of having one package to look after (which is why we moved from openhab2 to openhab) but there’s more the packages can do for the user experience. I find myself short in time at the moment, but I want to address this before the next major release.
A similar issue was mentioned which I also want addressed, in that many of openHAB’s users want Java to be listed as a specific dependency for the packages. i.e: The correct Java package should be installed alongside openHAB for those users who don’t maintain their own version of Java. This can’t be done on the main package as we ended up breaking the setup of those that do maintain their own versions of Java.
In which case we would have packages along the lines of:
I wonder is something could be done with the start script that kicks off OH if it cannot be handled in the packages themselves. It could run a quick java --version, some regex magic and if the major version number doesn’t match, generate an error message (at a minimum) and refuse to run.
Unfortunately such a solution would need to be added to the shell script(s) and .bat file(s) (or are we using powershell these days?) which I can see being kind of a pain but it can also be useful for people who install manually detect and understand a Java version mismatch problems too.
While these are all great ideas the most simple solution is still to not make the upgrade.
OP states that he didn’t want to update openHAB, so the upgrade was undesired.
The maintainers work very hard to make the updates non-breaking but it’s really hard because openHAB is a very complex application.
If we look at the history openHAB 3.3 broke HABApp, 3.4 broke UoM, 4.0 you know.
Semantic versioning is no guarantee that nothing will break expecially with an application as openHAB and in this case imho it’s doing more harm than good because it gives a false sense of security.
So why not do the simple thing and modify the installation instruction to pin the openHAB version?
Additionally to that we can additionally figure out a way to provide more convenience.
I’m aware what semver trys to achieve but this works only in a perfect world (see Hyrum’s Law) or
.
With an application as complex as openHAB every change will break something somewhere.
I already made two examples where 3.3 and 3.4 broke something not only for me but for multiple users.
Both times it was an unintended breakage and unintended breakage always outweighs intended breakage by far. So the only thing semver will do is give you a false sense of security.
Every update has to be treated as potentially a breaking update and thus it makes sense to properly pin the version.
Did the OP complain about breakages from 3.x to 3.x, or 3.x to 4.x?
I don’t know about the OP (someone flagged his post and it is now hidden, Why?), but I am simply wanting openhab to have the ability to remain within the same major version, whilst keeping up to date within minor versions, i.e. openhab3 remains at 3.x. so that someone can just install openhab3 and stays on openhab 3.x forever until a manual step was taken to upgrade to openhab4. This is a perfectly reasonable requirement, and one that should be able to be provided reasonably easily.
A ‘meta’ note from myself as a moderator:
the original post has been flagged by forum users as inappropriate and I agree.
This was not a constructive contribution for sure, even more so from someone being a developer as claimed the OP so he should well be aware of the implications that now were started to get discussed.
The OP also has not responded any more on this and given the OP’s (non-) history I wouldn’t take this for serious.
Personally I believe this is trolling.
Always hard to spot and distinguish this from valid user complaints so I may be wrong here @Ola_G let me know.
We have a slightly rising number of similar activity going on on the forum, intended to annoy and dismiss openHAB developers and community and pull away our attention, as has happened in the past.
I thought about splitting but left it because once you ignore the original post, title, category are about right.
I didn’t want to stop the discussion, go on. Just want to make you aware.
