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.
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
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.
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!
@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?
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!
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.
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.
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?
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.