That IS a pain then. Sorry but I am out of ideas.
You know, I also do some software development, and would sometimes even sympathize with your point of view. But in reality, it is rather arrogant!
For example, I was pretty surprised to discover that the backup archive included not only the configuration changes made by the user but lots of specific installation details (like paths etc.) which lead to the described problem. Now, I do not debate this approach itself, since Iâm sure there were good reasons for taking it. But I have seen this done differently in other software projects and cross version restores are NOT always a fundamental mistake, but even supported.
As an example, back in openHab 1.x days, the upgrade instructions pretty much went like: âcreate new install - copy over old config - doneâ
So I do think it is too easy, even for experienced users to fall into this trap. I do not say openHAB should allow for cross-version backups, but this is NOT documented well enough.
(Later edit: The problem weâre talking about ist not only that cross version restores do not work. If you try to restore a 3.1 backup to a 3.2 install you will break openHAB and have to do a fresh installation!)
Now can I fix it myself and send a pull request. Maybe but to be honest probably not. I unfortunately have too many eggs in my basket already and can easily avoid the problem in the future. Maybe I could add some warnings to the documentation, letâs see.
You donât need to be sorry. True, it IS a pain, but this is why I documented how to get out of it
I took a different route & left OH
I do
I also work in software industry allthough not as a developer.
It is good âbehaviourâ if the software keeps config data and project data as long as possible backward compatible.
Of course major releases require from time to time (3-5 years) compatibility breaks but those shouldnât be every year (but I have to admit I donât know how many of those breaks openhab had).