I think that OH is steadily moving in a direction that may allow “freezing” the core API for major versions. But I’m not expecting this to happen before OH3 as so much happened in the past months due to the ESH integration and the move to a new build farm environment. Take for instance a look at the numerous discussions on the GitHub project repositories.
For the ‘impatient enthusiasts’, I’d recommend to deploy a recent OH2 snapshot on another computer to see if everything works as expected. This is one of the safest ways to prepare your personal migration scenario for the next milestone. Many changes (bug fixes and new features) have been developed since the last milestone build, so expect some tweaking to your current setup.
The current REST interface and actually the entire addon part (composed of the karaf and core bundles) does not support versioned addons. I proposed changes via my Setup&Maintenance interface that does support versions, but that changed REST interface was not considered. So the real reason why we do not have versioned addons is probably simply because openHAB core can’t handle them.
I would formulate this differently: openHAB is highly modular (this is why you have so many add-ons to choose from and you don’t need to install one big single package). It is only that the distro build is building everything with a single version and there are many very good reasons for it - release processes, versioning, release notes, compatibility guarantees are all streamlined and much much simpler than if we had to do those 200 times for every single add-on separately.
Note that we had all those discussions many times before and the most efficient solution that we agreed on were the milestone builds - that’s what this topic is about. Having monthly stable milestones allow people to get fixes quickly without jeopardising their overall setup.
I guess the main reason why this discussion comes up again is because we are failing to provide milestone builds since January. This fact shows that we currently have enough problems to deal with and making it more complex by introducing separate versions/repos/builds/releases for 200 add-ons is clearly the wrong way right now.
Thanks, Kai.
I appreciate all the hard work, especially since the last release. I know nothing about Java programming & am just wading into the smart home stuff as a hobby and as time permits.
I am actually trying to work on a web based weather solution using the REST API to “scratch my own itch”. The fact I am using Python is mainly because I am learning it for work and it works well with JSON.
I am interested in the Hue Emulation Service as well, I see the service bundle for this on the sites you pointed me to, is there a folder/method for loading the hue emulation service like the bindings are placed in addons folder?
I am shooting for a perfect HABPanel here, just hoping to get somewhere close.
Edit: Disregard this request I have installed the latest hue emulation bundle and see that it can’t start since core automation changes.
The Jenkins build didn’t trigger the linuxpkg build. I’ve just done that manually now so expect the apt and yum repos to be updated within 5 minutes from now.
E: The repository 'https://dl.bintray.com/openhab/apt-repo2 testing Release' is no longer signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
I have updated the gpg keys per the instructions @Kai posted a few days ago.
Not sure if this is the correct forum, M2 upgrade went perfect. Hue binding, lutron binding, throughly vetted and works like a charm! Still adding new bindings. Will keep updated. Thank you to everyone involved. Loving the new build!
