Hi Stefan,
i’m still dealing with the 2.5.M1 Version, but for me it’s very easy to go back, as i made an image of my SD-Card from time to time, and naturally before an upgrade. I have 3 SD-Cards ( tested that the image fits to it), so I have no problems in case of crash or to restore an older version. It’s only the work you’ve done between the changes, but mostly they won’t work on the elder Release, cause they were the reason for the Upgrade.
Cheers,
Peter
THX
To explain it in more detail. What I did:
open ssh -> sudo openhabian-config
Point 40 openHAB releated
switched back from openHAB tesing to 41 openHAB release
Update and Upgrade System.
But it did not work. 
Luckily I create a backup every day and could go back to 2.4.
Afterwards I only exchanged the DB files and finished.
Sorry, no idea about openHABian, never used it.
Define “did not work”. OH wouldn’t start? Parts of OH stopped working? It didn’t change the version back to the release?
1 Like
I’m pretty sure you will have to purge the old package manually. So
- start openhabian-config
- make a backup of your configuration as you will lose it through downgrade
- Change openHAB release to stable
- end openhabian-config
- use
sudo apt remove openhab2 - use
sudo apt purge openhab2 - start openhabian-config
- reinstall openhab2 through openhabian-config.
- restore your configuration.
But I did not test this, so this is just a guess.
I thought the downgrade did not work.
After the completed actions, 2.5 M1 was still installed and running.
@Udo_Hartmann THX for the hint. Perhaps I try it in the future 
1 Like
When is the 2.5.0.M2 output expected?
When are the builds working again?
I’m sure there will be an announcement. David predicted another 60 days.
Isn´t openhab 2.5 (release version) suppose to be released in May/June?
I doubt they will be able to stick to the regular release cycle for this next release. The changes involved with remerging ESH into the OH baseline and changing the build system are extensive. But I don’t know anything more than you do about what is in the maintainer’s goals.
We are also actively pushing java11 support now.
But at the moment it really looks like openhab1 add-ons will not be part of any future release is my prediction.
Which of course doesn’t stop someone to just use the current version.
Wow. Wasn’t this subject of the “big OH3 direction” discussion? I’m a bit surprised to see this as an expectation already for OH2.5…
1 Like
It depends if a solution can be found for the fact that everything is using the new buildsystem except addons1.
1 Like
Ah, okay. Thanks. So a simple technical fact might overrule days of discussion 
As long as there is a build generating OH1 addon bundles and the compatibility layer remains supported I don’t see any reason to drop support for the OH1 addons. They currently also work fine with the snapshot build with the 2 build systems in place. But it is certainly not ideal for developers to use both PDE and bnd for development.
I don’t think it makes a lot of sense to put a lot of effort in migrating OH1 addons to bnd if the compatibility layer is removed in OH3.
3 Likes
Not to get too far off topic but if the OH1 addons are no longer supported, wouldn’t OH 2.5 more properly be OH 3, whether we are ready for it or not? It may not represent an API breaking change which I think is the current standard, but from a user’s perspective it’s a really big deal.
1 Like
Technical openHAB1 addons are just OSGi bundles like openHAB2 addons. There is a chance that they work. The bnd (new buildsystem) generated bundles have a more modern manifest file though that uses capabilites for dependency resolution. @wborn Do you know if that can cause issues with pde generated bundles? Karaf should still accept and resolve them, I guess.
1 Like
As we had discussed, further openHAB 2.x releases should bring no surprises (=major changes) at all - this also means to me that OH1 addons are clearly still part of the distro and that the distro can be run on Java 8. Anything else should indeed only come with OH3.
8 Likes