-
I wish the java 17 requirement will not be enforced on the addons so they can be used in the 3.4 stable release at least until there is a stable 4.0 (unless the J17 functionality is required for that addon). Using zwave as an example, there are many beginning and intermediate users (usually on Rpi’s) that go from stable release to stable release. However, the Zwave DB of devices (and thus the binding) is updated weekly with new and modified devices. From a support perspective I would not like to advise that the only way to get your brand new shiny zwave device working is to a) wait 6 months for a stable release or b) upgrade your Pi O/S to bullseye, upgrade to J17 and then upgrade to an OH snapshot (unstable). Although I haven’t tried (just back from holiday), I believe the latest Zwave binding DB update is working in a 4.0 snapshot and will still work in 3.4 stable.
-
Rethink the massive .kar file approach, I’m thinking along the lines of the Apple/Google/Microsoft store During an OH upgrade my Rpi3 (on wifi) struggles with a 370 meg file of almost 350 bindings of which I use 4. Multiplying this extra burden by every OH upgrade and hundreds of users makes me question the German stereotype of efficiency and engineering
I’d add that with about the half of the items in this wishlist the kar file will be 500 megs by the end of the year.
The ultimate would be that only the bindings that changed would be upgraded (like how the apt update works), but I see the kar files are distributed to tmp and that is cleared every upgrade. Anyhow redownloading 4 jars is far better than 350. I also think this would help reduce the “Kar loading 15 sec message” and the activity related messages at startup when installing a new OH version.