I also don’t want to repeat the compatibility discussion. But in terms of a possible timeline and the planned involvement of the community when it comes to testing, I would like to know whether there is something that can be reported.
Just to be curious, and because I find that very inspiring
I know there is a project board created and stuff is being worked. The replacement for PaperUI is coming along nicely. I don’t think there is a set timeline for when testing versions will be released so I wouldn’t worry too much about it. I’ll be surprised if the first betas get released by the end of next year. But I have no real insight into what the developers are thinking.
I suspect that a similar process as was done for the OH 2.0 release will be followed. There was almost a year IIRC from the first beta to the final release and there were three beta versions I think, maybe only two. There were alpha versions prior to that I believe but I was one of those “I’m not moving until 2.0 is ready” types at that time so I didn’t pay much attention to the alphas.
There will be announcements made, similar to how the current 2.5 Milestones are announced and I like the way a separate thread is created to list and debug any problems people have with each milestone. I’d like to see that continue for the 3.0 alphas and betas.
The difference between 2.x and a 3.0 is going to be much less significant than the differences between 1.x and 2.0 so perhaps the schedule can be compressed.
The biggest areas where community contributions will be needed is in updating and testing out the docs and filing issues for any regressions or problems or feature requests.
But we all need to be patient. I’m not sure if there is a planned 2.6 release or if 2.5 will be the last 2.x version. But now that development has picked back up again after the build system move and the merge from ESH (just look at the change log for the most recent milestone) maybe there will be a 3.0 ready, or a 3.0 beta will be released in June or July of next year. But I’m just guessing. Just sit back and wait for the announcements.
For the most part, the maintainers like to stick to a monthly milestone release schedule and a twice a year point release schedule. I expect that OH 3.0 will try to fit in with that sort of release schedule as well.
It’s relatively simple. Here is from the post from Kai:
In essence this is what openHAB 3 is about. All other changes are optional. It just depends on who is going to contribute what.
The change mentioned in the quote means it will break all existing code and thus not be compatible with older versions. But the good news is, it’s (mostly) only on source code level, thus a user should have minimal impact. It’s also a relatively easy change to make so I would expect when we make the switch I think it can be done in a short time frame.
All other features are optional. There are probably a lot of ideas. But it all comes down to have people contribute it. And big changes require a lot of time and that means it’s very hard to do when there are only volunteers who do it in their free time. So those changes can take some time to implement. But the breaking change will be there, and it could inspire to make more improvements.
It also comes down to providing a way for people to see if they can contribute. I have some UI ideas, primarily for Z-Wave but see no way of even testing or experimenting with this.
Yes the UI. Let’s say there is room for improvement. Currently it’s very hard to contribute in a small way to the UI. Because there is no UI I would want to contribute to. Some UI’s are basically end-of- Life. To make these kind of changes possible you want to make, we would need to have, preferable, some kind of pluggable UI like HA Lovelace. But just to get something like that will still require a huge amount of work. So yes it comes down to providing ways. But it’s not something easily fixable without people stepping up to make the big changes.
