I don’t know if it’s relevant, but I also mention it:
I think both of those would be relevant and useful information… I’ll added them!
If you’re expecting a lot of stability from a milestone build, you might be disappointed when running into issues like:
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 !!!
The first one is already in the list (#9), but the issue you linked provides some more details. I’ll add the SSE issue.
I agree with:
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.
Recreating your Kodi Thing might fix that because existing things aren’t properly updated. See:
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.
Just my two cents…
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.
I see all of these as critical…
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.
So not working.
@5iver I have created https://github.com/openhab/openhab-distro/projects/2 for further tracking.
- I didn’t include (1) as I understand that this might have been in 2.4 and 2.5.0.M1 as well - so no immediate regression.
- (5) Do we have an issue for this?
- (9) I thought to understand that the OSGi-ifying was only relevant for running the bundles in the IDE, but that they are working in the distro?
I did not experience this issue before the zibee and zwave bindings (the only bindings I have using serial) were migrated to BND.
There are several, but I don’t recognize one specifically for the issue David mentioned… https://github.com/openhab/openhab2-addons/issues?utf8=✓&q=is%3Aissue+is%3Aopen+hueemulation+-label%3Aenhancement+
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?
Something in between.
- 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.
Problems with the serial driver have been there longer, with symlinks not working proberly, and not optional from PaperUI. I cant tell for how long though, but this problem was in 2.4 as well.
The latest problems given zigbee and specially z-wave devices problems, was added somewhere in 2.5, where things went from bad to worse… Or in my personal opinion - a disaster!
It seems to be fixed for me with the changes in PR #866.
It’s only an issue when using bindings that use the new serial transport (
org.eclipse.smarthome.io.transport.serial) instead of
gnu.io directly. In 2.5.0-SNAPSHOT these are: DSMR, EnOcean, PowerMax, RFXCom, Serial Button, Smartmeter, Plugwise, ZWave.
It’s unrelated to the bnd migration. E.g. ZWave switched to using the serial transport in #1152. So the issue is becoming more visible now more bindings are being adapted/implemented using the new serial transport.