Development of openHAB 3.0.0 and 2.5.x

Announcements
1

All,

As already briefly mentioned in my openHAB 2.5 release post, I’d like to give you an update on the further development efforts:

With the 2.5 release, our master branches have switched to 3.0.0-SNAPSHOT. There are currently multiple bigger initiatives going on, such as the code refactoring to remove the Eclipse trademark from the code, the new default UI as a replacement for the Paper UI and others, the switch to Java 11, making the next-generation rule engine the main one, etc.
As a result of those activities, the current 3.0.0 code base is not yet usable, so please refrain from trying out any 3.0.0-SNAPSHOT distro for the moment. It anyhow does not include any add-ons, so it is rather pointless. We plan to have usable snapshot builds available in a few weeks from now.

Meanwhile, there is a lot of activity on the add-on development side by our gorgeous community and in order to not having to maintain two separate branches, we have created a 2.5.x branch in all add-on repos and are asking all contributors to create their PRs against that one - with the premise that those changes are fully backward compatible.

As we have also found a few bugs with the 2.5.0 distro (e.g. when using the downloaded add-ons), the @maintainers decided that we will release a 2.5.1 distro with updated add-ons (everything that is merged in the 2.5.x branches) on January 12. A snapshot build of 2.5.1 is already available on Jenkins as well as in the Artifactory snapshot linux repos for testing.

The 2.5.1 distro will most likely be the last 2.5.x distro. But this is now able to always install the most current 2.5.x version of the add-ons. We will therefore continue to regularly release 2.5.2, 2.5.3, etc. releases for the add-ons, so that there is still a chance to get the latest features and fixes as a 2.5.1 distro user.

This will most likely happen until summer as we then plan to switch all development (PR and merging) efforts back on master for all add-ons. Hopefully, we have some decent 3.0.0 milestone builds available by then, so that everybody, who cannot wait for any latest code changes has a chance to switch already.

I hope this all makes sense to you and that it works out as planned - let’s make it happen together! :sunglasses:

Cheers,
Kai

51 Likes
2

Thanks all.

Is this true also for 2.5.0 or just 2.5.1?

3

@Kai thanks for the great overview. I think many of us look forward for the upcoming releases.
Can’t wait for the next gen rule engine with jython support (!!)…

Happy new year!

1 Like
4

One probably relevant addition worth mentioning: The 1.x compatibility layer has been removed from openHAB 3.0.0.

@Bruce_Osborne Only 2.5.1. of the distro. In that version the changes were made to make it possible to add newer versions of the addons.

2 Likes
6

I’m not a 1.x power user, I’m only using the HTTP binding. I saw earlier that there is a rather old PR for a 2.x replacement, can we expect that this will be merged when 3.0 will be out (I mean stable)?

7

OpenHAB v1 h=bindings, such as Expire will not function in OH3, at least natively. All the URLs for v1 bindings end in the number 1.

8

Will openHAB 3.x still be built on Java8 or something newer?

I.e. for the KNX add-on the underlying calimero project has upgraded to Java11 and it is annoying to have to transpile the jars to Java8 and then build my own KNX add-on. (But it can be done for anyone in the same situation: https://github.com/petero-dk/javacrosscompiler)

9

See first post by @Kai

3 Likes
10

Thanks!, I read it twice but still missed that one. Now that I read the github issue through I can still not see if there is a definite decision on 3.0, but at least for the end of 2020 it will be Java11.

11

I think that initial decision by the maintainers is that openHAB 3 will only work with Java 11.

12

I have one question/point of clarification.

The core of OH will be frozen at 2.5.1 which makes sense. And I understand that the core has been modified so it will support later versions (e.g. 2.5.2) of add-ons. How will the discovery and installation of these later versions of the add-ons occur? Do they need to be manually installed (i.e. download and copy the jar to the addons folder)? Should users just clear the cache periodically to force a reinstall of the add-ons, picking up the new versions? Click on something in PaperUI? Do we know the answer yet?

6 Likes
13

Is there any documentation on how to migrate 1.x bindings? I’ll try to get started on migrating InsteonPLM when I get a chance.

14
1 Like
15

Also there is a list to track migrations:

16

When things settle down, are there plans to add an OH3 column?

17

I heard that OH3 add-ons will not work on 2.5.x due to namespace issues (fully removing/renaming the Eclipse smarthome components/name spaces).

How do we handle that? Will the master somewhen switched to the new namespaces? How to have ongoing support for 2.5.x users? If there anything I could do to have a smooth migration?

@Kai would like to see a slightly later release date for 2.5.1 so we could move the PR the 2.5.x branch and do a solid review. Maybe Jan 19 to give all of us the time to work on quality? I doubt there is or will be a good pile for the reviewers, which needs to be processed so everything gets in?

1 Like
18

Technically speaking it is possible in similar way as it was made for OH1 - by providing compatibility layer. We know what types were in OH2 and what packages are present in OH3. Mapping can be done at the build time or runtime by basic adapter types which will adapt org.eclipse.smarthome package to org.openhab.core.
It can be also semi-automated by basic IDE support falling into category of “migrate package” or “migrate jar”, depending if you are on IntelliJ or Eclipse.

19

My understanding is we are obligated to remove all references to org.eclipse.smarthome. Wouldn’t that obligation also apply to such an adapter?

20

I would guess that would need to be arranged through the Eclipse Foundation?

21

No. The table is only for oh1 addons.

That is correct. But that has no effect on the configuration. So a user can simply upgrade openHAB and it would still work (not taking into account other changes)

Master has already been migrated, see the post. At some point oh2 will be migrated to oh3 most likely with automated scripting.

This was also addressed in the post.

There will be other releases, see post, so that would not be a reason to postpone the release.

Even if technically possible there is no intention to do such thing, and because it’s only the namespace, not a change of interface change like with oh1 it relative easy to migrate a oh2 binding to oh3, unlike with oh1. Actual the code of core has been migrated with simple script. So adding all kinds of ide support is far more work than simply migrating a binding.

1 Like