openHAB 2.5.1x release discussion

Same here.
It looks like it is running an update in the background with no visual log displaying. Why?

As seen in the screenshot, for an unknown reason v2.5.12 is not found as installation candidate. Is anything wrong with my etc/sources.list maybe? Don’t think I changed anything, though, and all previous upgrades starting with v2.5.9 and onward went flawlessly so far…

Any hints appreciated.

You are looking at the testing repo. 2.5.12 is stable

I’m pretty sure I posted a reply to the issue, but my post seems to have gone missing :confused:

What is the output of:

apt-cache policy openhab2

The stable releases are available on the testing and snapshot repos, so this won’t matter.

A bad forum upgrade meant they restored from backup and lost a couple of days of posts. Not sure why they did not backup just before upgrading.

I was not aware of that

10 posts were split to a new topic: openHABian upgrade

@kai
Was 2.5.12 the last 2.5.x development? There do not appear to be 2.5.13 SNAPSHOT builds.

Yes, unfortunately 2.5.12 was very likely the last release. I simply do not have the capacity to do release management for 3 branches in parallel and 2.5.x was anyhow considered to only be continued for critical (security) bug fixes - which we did with 2.5.12. The Bintray sunset is an additional burden that makes any further release unlikely, since it would involve quite some efforts to deal with it.

That really impacts zwave which depends on database updates. Was there any advance warning to users or developers?

For me this seems to be a good time seperate data from code in the z-wave binding. I’m quite shure, @chris has had a good reason to combine them, when he started. Anyway i’ve never understood (nor questioned) mixing this up in principle.
I’m aware this might be a lot of work. But not to depend on a new software release to be able to use new z-wave devices might well worth it.

@Kai Where was there an advance notice announcement io users & developers about this?

Some of us are still using OH 2,5,x while waiting for OH3 to mature, especially in regards to the UI parts integrating with the zwave binding. @chris stumbled upon this breakage recently.

Bruce this is nonsense what you’re asking for.
There has been the overall announcement that there will only be 2.5.X to add security fixes for major security flaws in 2.5. That statement clearly implies that there will not be any other updates such as the zwave DB or any other part of the code so you must not expect any separate announcement on that. That’s the state of the nation, and I think that’s clear to everyone, including yourself.
Moreover, the current version of OH has changed to 3. So if you are still on 2.5.X you’re on an outdated version, implying there will not be any announcements whatsoever on that any more (except those security ones if applicable).
The current v3 might have a bug or not (unclear what you refer to here and if that’s true at all and even if true how impacting that is to users), but - bug or not - that does not entitle anybody to expect extension of maintenance for 2.5 hence there’s absolutely no substance that justifies asking for that, let alone in the way you did (you asked “where?” rather than “is there?”).
So as a moderator, I ask you to stop using that sort of wording, it’s nothing but provocative and leads nowhere. Thank you.

1 Like

Where was this stated? That may have been true for 2.5 core but the announcements I recall said bindings would be updated and that was true for awhile.

Then why were 2.5.13 snapshots released? Then why was 2.5.12 released? there were no security fixes, just updates on 5 bindings.

Apparently Zwave users cannot use recent devices on stable OH 3.0 either due to breaking changes in the minor version 3.1.0 snapshots.

That claim does not make sense. Either they run the 3.0 release OR a snapshot (which, by definition, is not “stable”).
Any change to the codebase after release cannot retroactively affect the release.

There’s not much use crying about this.
The problem boils down to -

OH2.5 core is frozen.
Anyone can release further update bindings for OH2, on a snapshot basis.
Not everything can be backwards compatible. Those might not work on OH2.4, for example.

zwave binding effectivel hardcodes devices. That design decision means you must release new snapshot versions.

It’s up to zwave maintainers to produce versions for OH2.5, and preferably advise a user procedure how to install them. It’s up to zwave maintainers to decide when to give that effort up.

It’s up to zwave maintainers to produce versions for OH3.x. It’s up to zwave maintainers to decide whether to confine that to snapshot releases, or contrive another version that is backward compatible to last full release.

AFAIK @chris is the maintainer although @wborn has updated some parts too,

Many people run snapshot bindings on releases and this has happened for years, before I even heard of OH.

In fact there was an installation script to do that on an August 2018 post.

Not since the move to bintray. @Kai has confirmed 2.5 is dead. Snapshot builds have been broken for over a month. Last zwave failure was 2 days ago. Last Addons failure was 10 days ago.The green coloured builds were not tried since the failures.

This has been discussed many times here, but one more time won’t hurt…

The reason is that OH core REQUIRES that the thing files are included into the binding. To do something different would require that a large part of what is in the core is rewritten into the binding.

1 Like

No - unfortunately it’s no currently possible to build the ZWave binding since the OH-Core artefacts are not being build. It might be possible to change the pom to fix this if there are still artefacts somewhere, but I’m personally not sure if that is the case since the repositories being used were (I think) removed (I’m not sure of this).

As above, if there are no artefacts for OH-Core on which to build, that is difficult. Maybe there are core artefacts still out there? Otherwise the ZWave maintainers will also need to build core artefacts - this can also be done of course, but it starts making things problematic for the “zwave maintainers” to produce these versions of OH2.5 that you want.

These are built as part of CI and the binding is updated regularly - this is not the issue and this discussion I thought was about OH2.

1 Like