Preparing the openHAB 2.2 release

Hi all,

stable branches are created now! Maybe the question against which branch a hotfix should go could be answered by @maintainers? To avoid cherry picking, stable branch would be better, probably?

1 Like

Any fix should always first be done on master. If it is decided (contributor together with the repo maintainer(s)) that it should go into a release branch, the simplest solution would be a cherry-pick by the maintainer. If it is a bigger change (which should be an exception for a patch) and there are conflicts, then it makes sense to ask the contributor to create a dedicated PR against the release branch.

2 Likes

Hi all,
our Jenkins release pipeline supports now building releases on top of branches as well. So technically, we’re able to do stable releases without big efforts now :slight_smile:

7 Likes

Hi Ganesh,

Yes, this would be awesome, thanks for volunteering!
As a matter of fact, the branches already exist (see e.g. https://github.com/openhab/openhab2-addons/commits/2.2.x), it is just that no PRs with fixes have been created for it by anyone yet. It would be great if you could help identify critical issues/bugfixes that should be ported to those branches and create the according PRs. We will make sure to merge timely merge them and create regular 2.2.x patch release builds!

Cheers,
Kai

3 Likes

I aggree. But I think this is not possible to handle (to much work).
In my opinion the only way is to split the OH2 distribution from the bindings.
Each binding should have its own version system and should check itself if it is compatible to the installed OH2 version.

This is what i do already. All the bindings i use are in the addon-folder.
The problem at the moment is, i have to compile the bindings i use by myself, and i have to test if the binding is compatible with the installed OH2 version.