60 days?
Wow, sounds like a big change. that worries me.
Sad I did not instal before…
It is a big change, but not a big functional change.
All of the code that used to reside at the ESH repo now resides in the OH repos. This means massive changes to the build processes for both the code and the docs.
Furthermore a new build system is being employed for parts of OH which is causing lots of swirl for the devs.
But none of this means functional changes to us the users. The code itself is not changing, just where the code lives and how it’s built is changing.
So it’s a big deal to the maintainers but for us as users it just means we need to be patient while they work this all out. At that point development will continue at the usual place.
5 Likes
yes I got it was no extra functionality. Still big changes is always big risk.
Combining multiple changes amplifies the risk.
smaller steps is lesser risks, even if twice times a risk.
I am taken by surprise, because I thought this change was already done.
I did not want to update my system before going to India, now it looks like a long time before updates,
which also adds another risk as many code changes are either blocked, or not tested by users…
It would have been nice to see some kind of warning, so I could have decided up front to install or not, now I / we don’t get that choice.
I’m not sure what gave you the impression that everything was done. Some parts of the merge have completed. As parts get completed they updated the original announcement thread.
What choice do you not have? You still have the choice to run the 2.4 release. None of the changes involved changes that. You can still have the choice to run the 2.5 M1 release. None of the changes involved changes that.
There IS no choice to run 2.5 M2 because there is no such release yet. That is what we are talking about here. The devs ran into technical issues with the building of the release builds (Milestone and Release) which is currently preventing creation of a release packages.
There have been tons of posts about the problems with the snapshots and it is discussed in the announcement thread as well.
I just don’t see what “choice” you had that was taken away.
2 Likes
I don’t know either. Yet the last one, was done pretty fast, no much downtime. AT least compared to the now 60 days of no releases
The current version I have running, many stuff is not working, like icons missing, connection to the cloud etc.
At this moment I can’t upgrade to a latest version.
(Or at least won’t until merges are done.)
What I’m advising the teams I’m working with, is to have at least one stable build, before changing a build system
On top, I prefer to do what’s called limiting red society: whatever changes we do, we try to have green builds almost all the time. (even when we do infrastructure changes)
Last team I worked with that changed build system that could not been done in a small step (years ago, most upgrades today do work in small steps) we made the changes in a branch that had no impact on the original build. So noone had any impact
I’m not stating these things shouldn’t be done, I’m trying to explain that there are options that have less impact and that usually have better results (Because the smaller steps, everything stays green and mistakes are faster found)
1 Like
And you forgot one important point: your are PAID. Everything here is volunteer work. No time for branches. The 2.5m1 release was made before the merge for the stated reasons as the “green” build btw.
3 Likes
As @David_Graeff already replied the “green” release is 2.5M1, and it is working absolutely fine.
Noone needs to run the latest stuff. While it mostly did, it isn’t guaranteed to work at all (which is mentioned on about every possible occasion).
If you use it then it’s because you want to, and you’re responsible for being aware of the consequences.
Downgrade to 2.5M1 and stop complaining.
And please keep this thread free of any such discussion. It’s the announcements category, see ?
6 Likes
What has happened to the MQTT-system-embedded-Broker, I am running 1561 and I go to addons —> Misc and it is NOT listed
Is there a reason for this?
The name is now Mqtt Broker Moquette. But you have probably tried to search for just “mqtt” I guess? Might be a packaging problem.
Everything here is volunteer work. No time for branches
you seem to imply that what I suggest is slower, what I’m stating is that it’s actually faster .
the “green” release is 2.5M1, and it is working absolutely fine.
That is great to hear, yet when there are problems, it’s impossible to have a fix for the next 60 days, and that’s what I’m worried about.
At this moment there are things not ok, yet I know the state (of my system) so I’m not upgrading (and yes that is my choice)
What I was asking is an announcement that things will be broken for a long time before doing such a large upgrade.
And yes I give some ideas how I helped teams optimize such upgrade processes, both paid and volunteers teams. Teams much larger and teams much smaller.(1 person teams)
Please dont’ use volunteer as an excuse to say we can’t do great work, because that just ain’t true.
Openhab is a great example how great stuff is done by volunteers.
You make it look I’m fighting against you, where I’m asking for better communication.
That is for the same cause.
I’m giving idea’s because I have that experience on making teams look for these ways of working.
4 Likes
Here is the problem.
-
None of the people who actually make these decisions and do the coding are reading these suggestions.So they are not being addressed to the right people. The maintainers of the core are not super active on the forum. If you want to get their attention you will need to post an issue on github.
-
The suggestions, while I’m sure are well intentioned, come across as “I know you didn’t ask, but I’m going to butt in because I’m an expert and you are doing it wrong because I say so as an expert.” I know that isn’t what you mean. You know that isn’t what you mean. But that is how they read which I think explains some of the reactions you are getting.
The suggestions are good ones. But we have the situation we have. Let’s let the maintainers finish what they are working on to get everything back up and running as it should be. Then (or even now) open a new issue and see if the maintainers are willing to conduct a lessons learned exercise and/or change their process or something. They are the ones who are making these decisions and they are the ones who are doing the work.
Until and unless you engage the maintainers your suggestions will be nothing but complaining, and not even complaining to the right people.
7 Likes
Yes, but that’s true that with all the underlaying work -needed but without any end-users added value- it’s quite difficult to give any approximation I suppose. I see all these PR flying regarding the build system change, it’s really a huge work engaged, and I suppose everyone is focused on getting it done because it has to be done instead of calculating when it will be over (that by the way could be more discouraging than anything else).
2 Likes
Is there a plan by when a next milestone release is planned?
1 Like
afaik as soon as the move to the new build system is completed (of course after some tests…)
Hello folks got a question on Milestone Builds. I am currently running on openHAB 2.5.0.M1 Milestone Build. I have a new zooz ZEN25 device that is showing up in the latest database at https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devices.
However it doesn’t appear to be in this milestone build. It displays an unknown device when I add it to my z-wave mesh network. In the past I was running the latest dev snapshot but ran into stability issues which is why I am on Milestones now. My question is simply, is there a way to run the latest and greatest z-wave binding while taking advantage of Milestone builds? I imagine that I could just dump the binding in the addon folders as I did in the past but I can’t find it. Maybe I am searching for the wrong thing. I am pretty sure that this would fix my issue with not being able to find a device that is in the DB.
1 Like
Sweet thanks a million!
I ran into an issue where the latest .jar wouldn’t work after uninstalling the zwave binding, putting the new .jar in the addons folder and restarting. In case anyone runs into this error in the openhab.log…“Unresolved requirement: Import-Package: com.thoughtworks.xstream;”
I can understand both maintainers and users…
What I can’t understand are words like “you have to be patient - we don’t get paid”
I worked with @milhouse to debug the squeezebox binding while I was on unstable 2.5.0
after updating I was lucky things work like expected. But after 2.5.0.M1 the complete MQTT Binding stopped working. This is an essentually part of my home automation. So I had switch back to the 2.4.0stable release.
But now I had to get the new binding working again… so I had to deal with karaf to implement only the updated binding to the 2.4.0.
So not everything is working fine with the so called ‘stable’ version…
The point is: I’m able to do stuff like this, but I think a user who is not familar with programming and code or the installation of a single binding gets stuck at this point and is maybe a little confused…
And no one wants to wait months for a fixed release - no matter if the maintainers are paid or not.
So if we want satisfied users, in my eyes we should provide new versions of older releases and add (tested & working) things to provide functioning changes to not so crafty folks.
Just a thought…
4 Likes
This is news. I’m using both versions of mqtt binding and have no problems. Did you file an issue?
2 Likes