The 2.5M2 release has been held up for several reasons. The main one has been the actual ability to build the release, but this has just been resolved (). However, there’s still the question of whether 2.5M2 is ready to be released. There have been many changes since 2.5M1, so I thought it would be good timing to get a post going with a live list of the current major issues that the testers in the community feel should be addressed before the release, as well as a list of new features that people will want to know about when deciding whether to upgrade. This is a Wiki post, so please add anything you are aware of!
The enumeration is just to help identifying the items… not priority/severity
Outstanding Issues
[core] Serial ports need to be added to EXTRA_JAVA_OPTS, even if they have valid names. Otherwise, the serial port dropdown will only contain the first port selected.github
[core] High load (there’s a working fix but there are open discussions)github
[ngre] Paper UI (JSON) rules fail to load after ESH reintegrationgithub
[ngre-scripts] Scripts do not load after OH startup on Windows github
[hueemulation] No Items are discovered github and once that is fixed, ALL Items are discovered unless they have been tagged with ‘internal’ github
[REST API] REST API Docs UI cannot find swagger.jsongithub
[core] Be sure to start the serial providers before the bindings using themgithub
[zigbee] IsAliveTracker incorrectly setting things OFFLINE (recently introduced with 1.2.1 libraries)github
[basic] Frame visibility in sitemap ignored until refresh github
Functionality fixes, improvements and changes since 2.5M1
[core] Package name changes, which can potentially affect people’s scripted automation (the helper libraries for scripted automation have been updated and are backwards compatible)
If possible and applicable, the tradfri binding issues with new ikea firmware update. Numerous threads in this one. I know an issue was filed on git but don’t have a reference right Now.
It is clear that from a milestone with stability one can expect, even in 2.4 there have been, it seems to me, 7/8 milestones.
What do you think is important for starting a milestone cycle?
I followed your enormous effort , but I lost myself among the many problems !!!
It’s hard to recommend someone to use a new milestone release when it’s very likely there will be critical issues right after installing it. It makes a bad impression on first time users who might immediately stop using openHAB. So it should work pretty well without resorting to all sorts of workarounds.
New channels to Kodi binding as well? There are new ones, but in the docs it stated that 2.4 includes currenttime and other channels already but I can’t see them. So if this is only included in 2.5 (and the docs are wrong) there are a plenty of new channels there also.
But on the other hand goal was to deliver a milestone every month and I guess quite some frequency is needed to get new features/bindings/bugfixes out to more people. Especially after the bigger technical change that will be required to spot the bugs to get to a next release.
Nevertheless a bug making the system generally unusable I’d suggest to be blocking (like the “[core] High load”). Problems with a certain binding I’d comment on when publishing the Milestone.
Perhaps we can learn something from a company like Microsoft (no flaming, please) with their Windows 10 release cycle? And it is similar to other release cycle with a ‘Release’, ‘Beta’, ‘Alpha’ type of approach.
Let’s take Windows 10 as an example. For the general public Windows 10 basically has three release cycles:
Stable branch (don’t even start! ) - released twice a year. In OH terms that would be like 2.4.x, 2.5.x, 2.6.x, 3.0.x, etc. to be released when ready.
Insiders preview ‘slow’ branch - released more frequently but no fixed cadence and reasonably stable, no known breaking issues. In OH terms that would be like a milestone release that is suitable for a wider audience, aiming at bi-monthly I would suggest.
Insiders ‘fast’ branch - released quite frequent, usually even more than once a month, but can have some issues/limitations. In OH terms that would be like a monthly release I guess, and the audience would be people that can work with releases and switch between them, troubleshoot, etc.
And for developers and daredevils, there are of course the nightly builds (snapshots).
The primary reason to bring this up and suggest to consider an intermediate ‘release branch’ is that I have the feeling that releasing a monthly milestone release that is stable enough for many users can be quite a challenge in terms of manpower needed. On the other hand, there is also a need for a fast release cycle to leverage the latest and greatest without great risk to break things (any change to a running IT system can cause issues, believe me, I know!).
For a wide audience OH will have to strike a good (subjective term, I know) balance between fast development/release and stability. As can be seen with HA, people like it’s features but hate its breaking releases. ‘We’ should be different.
I realise that a release mechanism like suggested also results in extra work, but I still wanted to bring it into the discussion.
This is exactly the plan - fix the blocking regressions and do a new milestone build by then. Milestones are not meant to be “release quality”, so no need to do a fine-grained issue tracking across all bindings etc. It is ok if milestones have bugs, but they should be usable in general.
@noppes123 Thanks for your input. I think what we have in place more or less exactly matches, what you describe: The official releases (target: twice a year) are the “stable” ones, the milestones are the “previews” and the snapshots are the “insiders” builds.
It is only that the whole bnd-build change disrupted our schedule since January and we didn’t have monthly milestone builds since then - this is what we are trying to get back to.
@5iver & all: What do you see as critical bugs left that need to be fixed before a 2.5.0.M2? The CPU load issue is imho one, another one might be the CCE in the SSEActivator. Anything else?
1. This one will cause issues for anyone using more than one serial device.
2. Definitely a blocker, but there may be a workaround.
3. A migration script needs to be built.
5. hueemulation is currently non-functional, and IMO, this should be a blocker due to the number of people using this binding.
7. Possibly related to 2.
8. Possibly related to 2.
9. allplay and bluetooth could have enough usage to call this a blocker
10. Blocker, but there may be a workaround.
I’m not as concerned about these…
Since this only affects NGRE on Windows after a restart, IMO it’s not a blocker.
I don’t have input for this one, as mqtt is working for my very limited (Owntracks) purposes with mosquitto as the broker.
The Mqtt binding works actually. Open issues are mostly enhancement requests if you see the Homeassistent part as still being in beta.
Unfortunately I lost the Mqtt Homeassistent contributor due to the buildsystem change.
The underlying paho library with its really sad state atm causes problems for script users though. I’m thinking of changing the library after OH2.5 has been released.
Hue emulation also works, but expects json type http posts. Alexa has a defect thought and is sending json with the mimetype plain. There is a fix pending on hueemulation to act more relaxed.
I could be mistaken, but I thought there was more to this PR. @J-N-K, could you please confirm, or were the issues reported for allplay, amazondashbutton, bluetooth, etc. something else?
Allplay has native code, this is not properly declared in the current bundle. This will be solved with the osgiified-bundle, it is also possible to add the osgiified-library in the /lib folder as a workaround.
AmazonDashbutton is not installing all dependencies (like XMPP). This can be fixed by removing “dependency=true”. For XMPP I raised #5707 because it is not depending on the OSGi dependency but some other problem. This oculd be done for dashbutton, too
BlueZ is a mystery to me. I reverted the lib upgrade done during the migration and added the native code. This SHOULD work and does in my testing VM. But there seems to be a difference between x86 and ARM, which I can’t explain ATM. I’ll see if I can find a Raspi somwhere in the basement and debug it there. Since I don’t own the hardware, it’s a bit difficult.
). However, there’s still the question of whether 2.5M2 is ready to be released. There have been many changes since 2.5M1, so I thought it would be good timing to get a post going with a live list of the current major issues that the testers in the community feel should be addressed before the release, as well as a list of new features that people will want to know about when deciding whether to upgrade. This is a Wiki post, so please add anything you are aware of!
, but I lost myself among the many problems !!! 
) - released twice a year. In OH terms that would be like 2.4.x, 2.5.x, 2.6.x, 3.0.x, etc. to be released when ready.
