Preparing the openHAB 2.2 release

All,

I think everyone is longing for a new openHAB release since a while, the next being 2.2.
The good news is that the maintainers have just decided to schedule it for December 18, so in exactly two weeks from now!

To make the release a good one, I would like to ask all binding/add-on developers to do their best to get their add-ons in a stable state - so rather focus on fixes instead of introducing bigger features or refactorings right now.
Furthermore, if you are aware of any breaking changes in an add-on since the 2.1 release, please add some information about the required manual steps to the draft release notes - thanks!

My wish for all our dear users would be to help testing the latest snapshot builds as much as possible and report any major and critical bugs asap. Don’t be too shy to ping me directly if you think there is any critical issue that must not be missed for the release.

Looking forward to a successful new release!

Regards,
Kai

25 Likes

It’s the paid edition :stuck_out_tongue:

3 Likes

Thanks Kai and everyone else for all your contributions - looking forward to the 2.2 stable. I switched for the first time to the snapshot builds 2.2 a few weeks back - had a few of the issues with the config files being slightly corrupted but the forum helped sort it very quickly.

I will try the current snapshot and try to document anything that seems to break to help

Stuart

1 Like

@Kai Overall, I think things are looking very good. There’s been an impressive amount of progress made since the 2.1 release!

It would be really nice, however, to clean up some of the exceptions that frequently show up in openhab.log when using vscode with LSP enabled.


I suppose this one could be worked around in the short term by raising the log level to ERROR.

Thanks @mhilbush, I agree, we should make sure that we don’t have such annoying log messages. I’ll wait what @sjka might be able to solve in short term - all the rest, which doesn’t really mean any bug, I will try to then change the log level configuration in a way that those messages are suppressed.

1 Like

2.534 kilograms

2 Likes

Thanks to all contributors for their effort.
@ganesh.ingle
Think about what you are requesting. OH does consist of a large number of bindings (amongst other parts…) , which are build by a large number of volunteers. Each new release has an number of new bindings comung with it.
Asking the maintainers to test all of them in depth, would require them to buy the devices that make use of those bindings. Such a requirement in an open source project is impossible, we would loose all volunteers, especially the maintainers!
And this is only one aspect to think about when requesting such testing.

I’m happy with the way new “stable” releases are published!

1 Like

@ganesh.ingle

I think the EPL v1.0 license is pretty clear of what you can expect.

  1. NO WARRANTY

@Kai How do the release cycles of ESH and OH 2.2 relate to each other and what does this mean regarding getting issues fixed for the 2.2 release now that there is a ESH 0.9.0 release?

1 Like

There is a topic on this, not decisive though…

My plan was to use the 0.9.0 ESH release in openHAB 2.2, but as there are already important fixes in post-0.9.0 now, I will create an ESH 0.10.0.b1 for the final openHAB release - so no worries, it isn’t yet too late for fixes in ESH!

1 Like

It’s nice to still have the possibility to fix things!

But having ESH inside openHAB is like having Rolls Royce engines in your private dreamliner jet! :smile:

1 Like

ESH has not only many contributions from openHAB side.
The initial ESH project is based on openHAB and was splitted from the “old” openHAB on purpose in 2013.

Further information can be found in the proposal:
https://www.eclipse.org/proposals/technology.smarthome/

You seem to have very little knowledge about ESH. Don’t know where you got those stats from, but my rough estimation is that openHAB contributions to ESH (including my own) do not exceed 20% of the work that is done at ESH.

5 Likes

Currently i’m using the 2.2 Snapshot, almost everything works as expected.

Thanks to everybody involved.

What about after the 2.2 release?
Should i switch to the stable branch?
Will there be still bugfixes in the stable branch or is this an exclusive of the snapshot?

2 Likes

People are tracking this thread because it’s supposed to be about the 2.2 release. Your comments here, while interesting, are off topic.

I respectfully ask that you open a separate forum thread for discussing your topic. Thanks!

4 Likes

Is there a corresponding ESH 0.9 (or the beta version that will be included with 2.2) draft release notes? One thing that popped up on me recently, that is not really a breaking change but may raise concerns, is the deprecation of DateTimeType.calendar. I was recently surprised when I started seeing a lot of these validation issues in my logs when saving rules that use .calendar…

The method getCalendar() from the type DateTimeType is deprecated

It would be helpful if the ESH documentation would include alternatives for .calendar and .getCalendar.

This is great! Nice work all!

How does one go about switching versions?
Is there a link with steps?

I have some issues with groups needing a OH restart to populate changes. Are u guys aware if this might be addressed in the 2.2 release? Thanks

  • Will there again be upgrade scripts for manual installations? (see OH 2.1 release notes)
  • There should also be a note about breaking changes in logging configuration. (see Karaf Upgrade)
  • It would be also helpful to tell users running OH 2.0 (and may be even 1.x) what to do, e.g. refer to previous release notes or start from scratch.