Development and release process - changes to stable branches

This is not meant as way to plug my extremely simple PR ( but instead to find out how we can get certain fixes out quicker.

Currently this particular PR fails to build due to master currently not compiling.

Additionally, the changes have been made against master which is not directly cherry-pickable back to 2.4.0 due to the ESH integration moving things around.

So what should I try to actually build this against? Are any of the milestone builds expected to be always buildable?

Secondly, assuming this particular PR is accepted, I would think it makes sense to backport it to stable - all it does is add another identifier for the onkyo binding to support another piece of hardware. Stuff like this is fairly unintrusive and I would imagine it would be in everybody’s interest to get this into the stable release as well?

Is there somewhere where it has been described how the release process is supposed to work and I just suck at googling?
Would it be possible to

The current build pipeline of OH does not support Backports. It is more a rolling release with snapshots than an actual versioned project.

So the main thing that made me explore OH as an alternative to HA, was the constant changes that have to be made due to the very rapid release rate but I think a lot could be gained if we had the possibility to make smaller releases with minor fixes such as the referenced PR while keeping things stable.

But of course, I don’t know anything about how the release engineering is happening here (the reason for asking).

Any thoughts on how you would like things to be?

It’s pretty much like with home assistant. The difference is that openhab core apis do not change that often so in theory later build add-ons work on older installations as well and other way round.

That is not true at the moment though because of the buildsystem change that was started at the beginning of this year.

The situation is a bit peculiar, because there was no OH release yet with the new buildsystem. And developed bindings at the moment will most likely only work on such a release or snapshot versions.

Once your PR is merged the org.openhab.binding.onkyo-2.5.0-SNAPSHOT.jar
will probably work just fine on 2.4.0 since the Onkyo Binding doesn’t have any additional dependencies that need to be installed.

We tested a similar use case for the Buienradar binding.

My issue isn’t so much getting to use the updated binding but rather making changes like this available to a wider audience.

I would off-hand think that cutting a 2.4.1 release with this and others like it would be the way to go, but if the entire process isn’t designed around allowing backports of changes to a stable branch then that of course becomes very tricky.

I am looking at OH to move from HA. I would hope & expect you test your code to minimize breakages before release. HA does minimal testing & it is not uncommon to see at least 2 patch releases during the 2 or 3 week life to fix issues that should have been caught in testing.

I realize major changes are happening. I am hoping 2.5M2 will be reasonably stable and the 2.5 release will not be pushed out to fulfill the month release cycle goal. IMO Home Assistant is feverishly trying to get to their goal of a 1.0 release. They are currently at 0.94.2. releasing every 2 or 3 weeks.

What David is saying is that I can manually load a version of the addon compiled against a later version of OH and load it on OH 2.4 - this has nothing to do with with the maintainers testing or not testing but simply how I can load an “unsupported” addon.

OK, thanks. Just a tiny bit paranoid.
I am planning on running OH with no bindings & setting up items for my Z-Wave Things to get the rules debugged in preparation for a more stable release with Z-Wave functional.

I have a quick Item question. Is an item only linked to 1 thing or could I link a `Christmas Lights item, for example, to 3 plugs?

Sorry for the off-topic.

I feel you. I’m also coming here from HA and for the same reasons as you.

As I understand it, one item is linked to one thing/channel combination but you can have items that operate on multiple items.

1 Like

You can link an item to multiple channels.
This is a hue bridge example:

Switch	WZL_TOGGLE "Wohnzimmer Ein/Aus"	<light>	(glightSwitches,glightWZ) { channel="hue:0210:0017884f6873:1:color,hue:0210:0017884f6873:37:color,hue:0210:0017884f6873:3:color,hue:0210:0017884f6873:54:color" }
1 Like

Thank you for that.
I have 3 Z-Wave plugs I plan on using for outdoor Christmas Lights so I will want to control all 3 together.

1 Like