I’ve seen the following categories to be the case:
-
If it’s not broken, don’t touch it until it breaks.
-
I’m mad that they dropped support for 1.x bindings and refuse to move to the newer equivalents.
-
I depend on a 1.x binding and there is no newer equivalent.
-
I shouldn’t have to do any work to upgrade; somehow OH should continue advancing and give me new features and capabilities but nothing I do now should have to change. (I want to have my cake and eat it to).
For category 1, all I can say is what that mostly does is make is so that when it does break, all that work you’ve avoided by not touching it is going to have to be done all at once while everything is broken. But we will do our best here on the forum to help.
For category 2, all I have to say is OH is an all volunteer effort. There was only one person who was maintaining the 1.x compatibility layer and that layer was becoming harder and harder to maintain. He got fed up and was no longer going to maintain it. Calls were made to find someone to volunteer and there were no takers. So the layer had to go. If there’s no maintainer for a complicated piece of code which is adding significant complexity to the rest of OH overall what else could be done? But the decision was not made lightly and there were ample opportunities for someone to step up and keep the support.
For category 3, that’s the reason the Remote openHAB add-on was developed. The developers tried to mitigate all possible problems they could think of. Even today there are still some users running an old 2.5 OH with the Remote OH binding to continue to use a 1.x binding for which there isn’t a 2.x equivalent.
For category 4, I’m sorry but I have no sympathy for you. It’s an unreasonable expectation. But you’re not going to find it better over on HA which, as I read more in their github and on their forums, has almost a contempt for their users when it comes to “non-backward compatible changes”.
And it is very true, that the upgrade from 1.8 to 2.0 was was very hard because all the new concepts of Things, Channels, and Links were introduced (which enabled automatic discovery of devices which was impossible with 1.x) but that was the very first one, it’s bound to be hard.
The upgrade from 2.5 to 3.0 was nearly as difficult primarily because 1.x bindings were dropped and changes that needed to be made to rules because of changes to the underlying Java which the OH project had no control over. There were also a lot of non-user facing changes required as OH dropped Eclipse Smart Home and modernized the build system which limited the amount of attention that could be paid to making the upgrade painless and easy.
But the upgrade from 3.0 to 4.0 was super easy with only a few breaking changes that end users had to deal with and even among those the users who were primarily affected were text file config users as the upgrade tool was able to “fix” the breaking changes automatically in many cases. A number of PRs and issues are in work to make this even easier in the future for end users, possibly even with support for automatically upgrading Things, running old bindings on a new OH core, and stuff like that.
It’s almost as if openHAB as a project is getting better and maturing with each new release.Maybe the developers actually are trying to make upgrades easer and better for the end users.
I’m glad you are happy on HA and I hope you continue to be so.
In truth, it’s no more difficult than upgrading from 2.5 to 3.0 really. Nothing that 4.0 “broke” is relevant to a 2.5 configuration. You’ll have to fix all the same stuff you’d have to do for 3.0 but 4.0 introduces nothing else that would need to be fixed. The breaking changes in 4.0 are changes to the way features introduced in 3.0 work. There is no “legacy compatibility” lost in 4.0.
But I think the overall point of this whole thread is if you have moved to HA because you think HA is better than OH about preserving “legacy compatibility” I suspect you will be sorely disappointed.