openHAB Milestone builds

Not at this time. There was a massive change to the build system that didn’t go smoothly. There was also the big merge of ESH back into OH. I believe the developers are currently working down a bunch of bugs that have been discovered to get to a more stable state before they make another milestone release.

Because of the lack of milestone releases, I don’t know if they plan on trying to stick to the roughly every six months release cycle for point releases.


I personally would rather they keep working toward a stable release rather than rushing to meet an artificial deadline.


You need to switch to the testing repo:

For manual installation just dl, unzip and put your config back in.

I would have liked to, but we already missed that - so it’s rather gonna be late summer. But as others said: Top priority is to get decent milestones build again. After this, we can decide on a release date.

You need to switch to the testing repo

This is only relevant for apt, but @dbadia is asking for the “plain” update script.
@dbadia: sudo ./runtime/bin/update 2.5.0.M1 is the correct version and it works for me. Not sure, why you get a 404… The requested url is, can you check whether you can reach it manually?


I am able to access it manually from the server. I downloaded 2.5.0.M1 manually and diffed the update script from the zip to the one in my install. My update script had bintray instead of jfrog. Copied the new script over and the update ran OK


I mentioned point releases over here Development and release process - changes to stable branches (apologies for cross posting if that isn’t allowed), but this seems to be the more relevant thread.

So we have a case now where the much improved mqtt support in 2.4 actually doesn’t work with Homie devices after an OH restart - MQTT 2.4 binding: Items go to UNDEF after reboot. I understand that the whole build system has seen significant changes due to ESH being phased out, but the fix for Homie devices is already in master and seems like probably the most important fix to get out.

Is it realistic to get such changes backported to 2.4.1 and a release cut? I am sure there are plenty of people who would very much prefer to stay on stable but still get fixes in.

Couldn’t people just use the newer binding?
I am running 2.5M1 with a couple of snapshot version bindings.
I think 2.5M2 (or 2.5 Release?) is pretty close anyway.

sorry for the trivial question, I’d like to update from the stable 2.4 version to the 2.5 snapshot version. Since it is the first time I upgrade with a snapshot, can I use these instructions?

thank you

Those instructions should work.


I think homie support is still broken even in current snapshots. Perhaps the specific problem you are referring to was fixed but it’s still not working dependably.

Of course, but instead of telling people to get random snapshot versions of the various bindings that have received fixes (which may be mutually conflicting), isn’t it a far better user experience to cut a new stable release?

I’m thinking something along the lines of what the KDE project does - one feature release every 4 months and then fixes in the point releases (5.16.1, .2, .3) in the weeks following a feature release.

Thanks - I haven’t tried the snapshots.

The devs have been very busy merging ESH code as well as totally updating the build system. For quite a while the software would not even build.
This is developed mainly by volunteers. If you want more frequent bug fix releases then Home Assistant has that but, in my experience, you lose reliability.

Our current release manager guy doesn’t like multiple different versions in one repository, which would be a requirement for backporting “point” releases. Stupid IMO, because each addon has its own development and breaking changes cycle and semantic versioning would be really nice to have. But that’s how it is.

Cheers, David

1 Like

Would’ve been very nice if a user could choose binding version in paperUI, so you could easily upgrade a single binding to snapshot release but still be on a M or stable build (this of course with a warning message “at your own risk”) :slightly_smiling_face:

It is not guaranteed that using newer versions of bindings on older versions of OH. This might work but might also fail.

1 Like

There are sometimes other dependencies. OH2 is designed as a monolith, not modular.
It would be a major design decision to change that now. Likely more work than what the are dealing with now.
Home Assistant is quite modular. I am sure there are others. I personally prefer the stability here.

Ask your favorite binding developer to publish the binding to the IoT Marketplace:

(Although I’m not sure what the status is now that ESH has been sourced into openHAB)

Hm, I don’t understand why it would be a major design change? You can still do this manually by putting the snapshot jar file in the right directory, this would just make the job easier through UI…or am I missing something?

Changes made to the core. To support multiple versions of bindings that would require for the latest and greatest version of OH to still expose the same API to the binding as it did X versions back. That greatly increases the maintenance overhead and making changes to the API will become much more involved.

You can sometimes drop a binding of a different version into addons and it will work. But if that binding happens to use part of the core API that changed then the binding will not work.

1 Like