Don’t know, if that’s the right category, but do we have some kind of roadmap for openHAB, especially with regards to OH3? To see, what’s planned for and what we aim for with the upcoming releases? I searched here and on github and didn’t come up with something, but would be nice to have some kind of rough estimates on functionality and bindings?
AFAIK it is planned to have openHAB 3.0 released end of December 2020. Basically it will come with a commplete new UI concept, which makes the start into openHAB easier for new users but not only for them. Textual config will be possible as well.
It is expected all openHAB 2.0 bindings to be transfered to openHAB 3.0 plus some new features for several bindings.
This is just a very small overview about what we can expect…
@hmerk I think that Thomas like to know more about the upcomming features. #metoo and not everyone is familiar with github
@binderth Unfortunately, and there is no real proof about that, is my impression that @ysc post more about the Ui design on twitter than here in the community. And imho great stuff that is coming on the ui side
yeah, I know, there’s something coming wrt 3.0 and there’s a bit of information here and there (including twitter)… but me personally find it cool to have some sorts of “roadmap” somewhere, so we all can see what’s in there.
I find the SAP roadmaps helpful - and they’re not even “features-only”, but also include some stability features or integrations or whatever. I don’t think in features and bindings only.
…I’m aware, it’s sparetime only, but perhaps some sort of roadmap already exists and I just didn’t find it…
I can think about some other thing that are coming: What about rules, semantic tagging, the user system, Java 11, …
All these at least in my opinion are interesting thing. So a short note about these things as an announcement (no discussion) would be great. @ysc hast just startetd some tutorial about the new pages feate in the ui, (Great stuff) but for me the big picture is missing.
Nope, the new UI concept needed changes to the REST API. These changes are not going to be backported to openHAB 2.x core.
There is also the introduction of authentification layer and user roles.
Removal of ESH references had to be done cause the ESH project is archived and no longer maintained. This has nothing to do with Kai leaving as the project lead.
And that’s definitely not the only reason for a major release, as you can read here
The Road Ahead
Having the framework code under our control, I think it is a good moment to start planning how openHAB should evolve in future. There were many discussions in the past about the bad UX especially for newbies, with too many different UIs and options and the tricky balance between textual and GUI-driven configuration. Imho we should not make any fundamental changes to openHAB 2, but we should start talking about an openHAB 3, which can bring simplifications by reducing complexity (like retiring UIs, removing Xtext from the core, etc, tbd.) with the cost of breaking backward compatibility (while keeping a migration path for everyone).
No. This is from the Eclipse Foundation Trademark Usage Guidelines:
Nobody other than Eclipse open source projects may develop or maintain software packages that use ‘org.eclipse’ in their namespace. An important use of the ‘Eclipse’ Trademark is the ‘org.eclipse’ string used on all namespaces for Eclipse open source projects. This naming convention is used to identify code that has been developed as part of an Eclipse open source project.
There is certainly a relation. After DT left the ESH project basically only openHAB developers remained. When they left there was nobody else so the only thing that the eclipse foundation could do was to archive the project.
The namespace changes in core means no compiled add-on will be compatible anymore. That could be considered as a major change. While it has few impact on functionality, it validates a major release imho.
@hilbrand Does that not conflict with the plain reading of the license agreement though?
Contributors are defined as possibly distributing too.
3.3 Contributors may not remove or alter any copyright, patent,
trademark, attribution notices, disclaimers of warranty, or limitations
of liability (“notices”) contained within the Program from any copy of
the Program which they Distribute, provided that Contributors may add
their own appropriate notices.
That explicitly disallows removing the trademarks.
To get back to the original topic. I think roadmaps are a bit of a thing with openHAB. Mainly because the current structure is a collaboration of individuals. Meaning only if someone contributes something there will be something new and this is hard to plan because its on a totally voluntary basis.