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?
Thanks!
Kind of an answer:
yes, thanks! I read that, but it doesn’t exactly work as an roadmap! 
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
Apart from the UI perspective, I am not aware of really new cool features cuming with openHAB 3.0.
@ysc could you please elaborate a bit what new features can be expected with the new UI.
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.
Since the UI uses the REST API it could have just been released on OH2 then.
In my personal opinion refactoring OH to remove ESH references because Kai left ESH is a poor reason for a major release. I will admit Java 11 compatibility is long overdue though.
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
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).
OK, I summarized this under the new UI concept …
OH could not just fork it without renaming within OH?
This is above my skills, I cannot comment on this, but I guess there had been valid reasons not to just fork ESH.
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.
source: Eclipse Foundation Trademark Usage Policy | The Eclipse Foundation
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.
Source: https://raw.githubusercontent.com/openhab/openhab-distro/2.5.x/LICENSE
I changed the category
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.
That having said there is a project wide board for openHAB 3 to track progress. It’s probably not completely up-to-date or complete but gives an idea. https://github.com/orgs/openhab/projects/3
(This board was previously not open, but it is now)
For addons specifically we track milestones. For example you can see what is already merged and what will be in the next release: https://github.com/openhab/openhab-addons/milestones
While reading the discusssion about a road map i thing that “developer” have something different in mind tha “users”
In my world a roadmap give me a vision of the upcoming things, not a detailed projekt plan or a feature complete description. And i thing noone will blame anyone if a possible goal is not reached.
Just tell us what you ar working on on a high level. The information that the version number in the skeleton script need to be updated is to most people meaning less
Example Roadmap on a high high level:
By end of 2020 we like to release OH3 with the following new feature
See below for some more deatils and ideas on …
We like to release an early stage aplha by end of Septemne (Not ready fpr Produktion)
By End of october the UI should be mostly final
and meanwhile we try to upgrade all binding to version 3
Hope this gives a short view how i see a road map. And as i wrote in another thread: I have the feeling that i find more information about OH3 on twitter than in the community.
Sp great job KUDOS to all maintainers.