The question is basically directed to the @mantainer group.
I have in mind some interesting bindings to develop (the Particle binding for example could be of huge interest to a bunch of people).
However I am quite concerned about the deployment workflow.
It looks to me that a great effort (by @hakan and @watou) is going toward the direction of “normalizing” the existing pull requests on 1.8 in order to have it deployed in a production state.
Moreover, from what I can understand, 1.8 will be the last 1.x production version (I can imagine that a 1.8.1 bug fix version could be potentially released but nothing more on the 1.x branch).
Said that, both in order to avoid a greater workload to the mantainers group and in order to develop something on the “alive” branch it looks that I should start develop new bindings on the 2.0 branch.
However in my opinion, looking at what happened in the last year, I guess that in order to have 2.0 in production at least 1 year should pass; and that means that any 2.0 binding will really get alive not before 2017.
Which is the desirable direction for new bindings development?
Although I’m not the one to answer this question, here’s my personal opinion: If you want your bindings to work on 1.x, write to that target, because the existing body of bindings are going to be maintained well into the future. The 1.x codebase will remain home to 1.x addons, even if the other components aren’t planned for later releases. But if you think you and your users can wait for a production-ready OH2 to be available, there are advantages (like discovery) that would be valuable in your cases, and you don’t need any 1.x compatibility, go straight to OH2. Just my personal opinion.
I am fighting with the same thing as well
I agree with @watou for the 1.x compatibility. Especially if you want your binding to be used by people who set up their OH server and forget about it until next release… Which should be the majority of users if OH is successful for a broad user base.
I actually have two bindings I am developing, one adapter to owntracks ( New binding for mqttitude / owntracks ) and another for custom-built hardware ( Proper source place for a binding with (very) limited audience ). For both, I will target OH2 as I like hacking on the bleeding edge.
Also, I hope that we can move the OH2 release faster now that we have a larger maintainer group which can help Kai on upcoming issues.