openHAB Milestone builds

OS: Debian 9.5 Stretch

Die folgenden Pakete werden aktualisiert (Upgrade):
  openhab2
1 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Es müssen noch 0 B von 74,8 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 6.419 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
(Lese Datenbank ... 154397 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../openhab2_2.4.0~M4-1_all.deb ...
: not foundkg/info/openhab2.prerm: 2: /etc/default/openhab2:
dpkg: Warnung: Unterprozess altes pre-removal-Skript gab den Fehlerwert 127 zurück
dpkg: stattdessen wird Skript aus dem neuen Paket probiert ...
: not foundkg/tmp.ci/prerm: 2: /etc/default/openhab2:
dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/openhab2_2.4.0~M4-1_all.deb (--unpack):
 Unterprozess neues pre-removal-Skript gab den Fehlerwert 127 zurück
: not foundkg/info/openhab2.postinst: 2: /etc/default/openhab2:
dpkg: Fehler beim Aufräumen:
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 127 zurück
Fehler traten auf beim Bearbeiten von:
 /var/cache/apt/archives/openhab2_2.4.0~M4-1_all.deb

I think I know the answer, but just in case… Is jumping between milestones and releases easy as long as I only go forward? As easy as a few apt or dpkg commands? Or are caveats and gotchas likely to arise?

I’m struggling to imagine that upgrade scripts could handle the complications of varying repos, versions, and trains. I feel like I have something to learn here.

I figured my charting problem out - since I’m using both mapDB and rrd4j persistence, and my “Default Persistence” setting in PaperUI was set to mapDB, that’s what caused the problem. As soon as I changed it to rrd4j, the charts reappeared.

1 Like

No!
Well, jumping itself is as easy as that, but there can be gotchas depending upon the versions you change from and to.
For example, the most recent testing milestone introduced a reworked ZWave binding that requires you to delete and redo all of your things after an upgrade for OH to keep working. Likewise on downgrade, too.
So be cautious upfront and get to know the differences of those versions you’re changing between.
Normally upgrades are straightforward and there’s no such quirk, but the point is you need to be prepared.
A lot of people make the false assumption that there’s some sort of comprehensive regression testing (i.e. “everything that worked in the older version is tested again and still works”) on new releases.
Be aware there is not.
(well of course there’s quite some testing against every release, but it’s not comprehensive.)

PS: and never forget to clear the cache on changing version

2 Likes

You’ve helped me refine my question.

Let’s first pretend there are no breaking changes in the add-ons. From a strict package install and upgrade standpoint only.

  1. Can I manually upgrade my 2.3.0 apt-installed openhab2 on Ubuntu to 2.4.0.M4 (perhaps using a file linked above by Kai), and then…
  2. Can I hop back onto main apt repository once the final 2.4.0 release is out?

After answering that:
3. What is the approximate probability of encountering time-consuming problems if I upgrade at each milestone (including ~5 add-ons). I know it’s hard to say, but are we in the range of 10% probability at each milestone or more like >50%?

Yes, but that requires you to rework your ZWave things.

EDIT: sorry, misread

Yes you can.

Come one, that’s a silly manager type of question.
The answer depends on your knowledge, thoroughness etc.
Second, noone knows, and it’s all different among releases. Any answer to that is pure guessing.

Is jumping between milestones and releases easy as long as I only go forward?

Yes, I think as long as you make sure that you always update to a newer version when switching repos, there should be no issue (that is, no other issue than you might encounter with an update when staying on the same repo).
So it should be no problem going from 2.3.0->2.4.0.M4->2-4.0-SNAPSHOT->2.4.0->2.5.0-SNAPSHOT or similar.
Note that the update script now also supports the milestones, so if you are not using apt, but the zip distribution, you can easily switch between different versions.

Markus pretty much said it all but I wanted to elaborate on this some.

As a rule of thumb the amount of time that it will take on your part depends on the number of breaking changes and the number of until now undiscovered bugs. Obviously no one can predict that which is Markus’ point.

However, the more frequently you upgrade, the fewer changes there will be between versions so the overall number of these breaking changes and undiscovered bugs will be less. So theoretically it should require less time over all to upgrade from a release to each milestone along the way. Well, maybe not less time, but the time spent will be spread across more short sessions instead of one long session if you only work with the releases.

But, like already said, no one can predict how much time it will take you or anyone else to achieve an upgrade. Most of the time the upgrade will likely not require any work on your part. But if you are using zwave, the amount of work when going from M3 to M4 will be relatively significant.

Thanks gents. I understand it now.

Is it worth starting a new thread for each milestone build? Could be handy for devs to add some of their own release notes to users (like the zwave breaking change) and a place for people to validate issues, as opposed to starting new threads, etc. I went from 2.4.0.M3 -> M4 and had to roll back due to temperature scale not working properly on some zwave devices and all my Sonos things had issues (possibly linked to the sslcontextfactory exceptions in the logs), however it’s hard to know how best to move forward on these and if it was just me or affecting everyone. On the plus side, rolling back was a breeze with apt-get!

1 Like

Hi. How did you rollback to M3?
My Xiaomi binding in M3 worked flawlessly. Since updating to M4, I’ve gone back to getting “‘getEvent’ is not a member of 'org.eclipse.smarthome.core.thing.events…”

First grab the history : sudo apt-cache show openhab2
Then “upgrade” to the required version, in this case : sudo apt-get install openhab2=2.4.0~M3-1

What frequencie are we aiming for with Milestone releases? Just asking as it has been a while. I know that there is no precise answer. But are we talking once a month or more once a quarter?

If I remember correctly, in the first post, Kai said the plan for Milestone releases was approximately monthly

I read a lot about the different available builds now, but - maybe i just got lost in translation - can anyone here try to explain the differences between Stable, Snapshot and Milestone?

from my understading
a stable release is something that has been tested pretty intensivly and only happens once in a while e.g. 2 times per anno
a milestone build is something that incorporates actual changes bugfixes and stuff, hasn’t been tested comprehensivly (like @mstormi said :slight_smile: ) and happens like once a month
now where do i find snapshots? are those something “inbetween” the others?

i’m just trying to find out which docker image best fits for me…
i don’t have a problem with going for milestone even if that means i have to do some research or some work like redoing all my things because of the z-wave change as i think i can only learn from that…but i’m a little bit confused right now… :open_mouth:

  • snapshot: all the code that has been merged to the baseline up until yesterday, there is a new snapshot release every day
  • milestone: a snapshot that has no known bugs at the time it was created, the goal is for one a month but I think it has been more than a month since M4, not all changes will necessarily be announced
  • release: a tested and fully documented baseline

If you are using Docker, just choose the desired image version. For example the 2.4 snapshot image would be

openhab/openhab:2.4-snapshot-amd64-debian

One other thing you might want to know about snapshots… It’s possible that any snapshot build is broken in some way. Although it is much more infrequent than it has been in the past, there are occasions where a snapshot build will break existing functionality, sometime badly. When that happens, it normally takes a day or so for the issue to get sorted out.

OTOH, running snapshot builds gives you immediate access to new functionality. This is why I’ve been running snapshot builds on all three of my systems since day one.

If you decide to run snapshot builds, having a good backup regimen becomes really important. :wink:

M4 was on Sept. 25 and 2.4.0.M5 is… NOW!
I just finished building and releasing it - so almost within one month again. :slight_smile:

It includes a few important changes:

  • The newline issue in the ssh connection has been fixed.
  • The instance shutdown upon VS Code disconnect is solved (openHAB again keeps running)
  • HABot is included (the new Chatbot UI)

And here’s some more from Jenkins:

  1. updated to 1.0.33 for new zigbee libs (detail / githubweb)
  2. Set maven-install-plugin version to 2.5.2 (#408) (detail / githubweb)
  3. prevent System.exit() calls (#409) (detail / githubweb)
  4. Adding new ESH bundles as dependencies (#411) (detail / githubweb)
  5. Integrate ESH authentication features in openHAB (#412) (detail / githubweb)
  6. Revert “Integrate ESH authentication features in openHAB (#412)” (#414) (detail / githubweb)
  7. added new semantics bundle as dependency (#415) (detail / githubweb)
  8. Small change to highlight the mandatory use of the everyMinute strategy (detail / githubweb)
  9. Fix spelling in maxcul readme (#5673) (detail / githubweb)
  10. Eliminate the null pointer exception in the getHost method. (#5669) (detail / githubweb)
  11. [RRD4J] Fix NoSuchMethodError when using Java 9/10/11 (#5675) (detail / githubweb)
  12. fixed version of maven-install-plugin (#5676) (detail / githubweb)
  13. added 1.x to mqtt binding label (#5678) (detail / githubweb)
  14. Small change to highlight the mandatory use of the everyMinute strategy (detail / githubweb)
  15. Fix spelling in maxcul readme (#5673) (detail / githubweb)
  16. Eliminate the null pointer exception in the getHost method. (#5669) (detail / githubweb)
  17. [RRD4J] Fix NoSuchMethodError when using Java 9/10/11 (#5675) (detail / githubweb)
  18. fixed version of maven-install-plugin (#5676) (detail / githubweb)
  19. added 1.x to mqtt binding label (#5678) (detail / githubweb)
  20. Small change to highlight the mandatory use of the everyMinute strategy (detail / githubweb)
  21. Fix spelling in maxcul readme (#5673) (detail / githubweb)
  22. Eliminate the null pointer exception in the getHost method. (#5669) (detail / githubweb)
  23. [RRD4J] Fix NoSuchMethodError when using Java 9/10/11 (#5675) (detail / githubweb)
  24. fixed version of maven-install-plugin (#5676) (detail / githubweb)
  25. added 1.x to mqtt binding label (#5678) (detail / githubweb)
  26. Small change to highlight the mandatory use of the everyMinute strategy (detail / githubweb)
  27. Fix spelling in maxcul readme (#5673) (detail / githubweb)
  28. Eliminate the null pointer exception in the getHost method. (#5669) (detail / githubweb)
  29. [RRD4J] Fix NoSuchMethodError when using Java 9/10/11 (#5675) (detail / githubweb)
  30. fixed version of maven-install-plugin (#5676) (detail / githubweb)
  31. added 1.x to mqtt binding label (#5678) (detail / githubweb)
  32. Database update (#1016) (detail / githubweb)
  33. Add null check when processing wakeup time config update (#1017) (detail / githubweb)
  34. Update queue management (#1018) (detail / githubweb)
  35. Database update (#1019) (detail / githubweb)
  36. Add new tamper notification type and update MS-100+ (#1020) (detail / githubweb)
  37. Database resync (#1021) (detail / githubweb)
  38. Database update (#1022) (detail / githubweb)
  39. Database update (#1023) (detail / githubweb)
  40. Process node state events in the thing handler (#1025) (detail / githubweb)
  41. Ignore any configuration updates that do not change values (#1028) (detail / githubweb)
  42. Database update (#1030) (detail / githubweb)
  43. Add alarm_emergency channel (#1033) (detail / githubweb)
  44. use SecureRandom to generate S0 security key (#1032) (detail / githubweb)
  45. Don’t set the device online once static is complete (#1035) (detail / githubweb)
  46. Database update (#1038) (detail / githubweb)
  47. Add door_sensor channel from door lock command class (#1037) (detail / githubweb)
  48. Database update (#1039) (detail / githubweb)
  49. Alarm and multilevel sensor report updates (#1042) (detail / githubweb)
  50. Database update (#1043) (detail / githubweb)
  51. Database update (#1044) (detail / githubweb)
  52. Add information on debugging (#1045) (detail / githubweb)
  53. Update README.md (#1046) (detail / githubweb)
  54. Database update (#1047) (detail / githubweb)
  55. Remove unnecessary debug in on off converter (#269) (detail / githubweb)
  56. Update defaults and options for PANID and channel (#265) (detail / githubweb)
  57. Fix error defining static thinguid (#256) (detail / githubweb)
  58. Remove the node from the ZigBeeNetworkManager when the thing is removed (detail / githubweb)
  59. Synchronise AtmosphericPressure converter attribute processor (#262) (detail / githubweb)
  60. Synchronise attribute processing in level converter (#263) (detail / githubweb)
  61. Protect against getNodes being called before network is up (#264) (detail / githubweb)
  62. Add trace level logging into channel detection (#251) (detail / githubweb)
  63. Add door lock state channel (#254) (detail / githubweb)
  64. Initial code additions for setting join key, and support for Ember (detail / githubweb)
  65. Minor updates for Ember config and Bridge config updates (#271) (detail / githubweb)
  66. Fix minor bugs in on/off converter (#272) (detail / githubweb)
  67. Add ASH protocol statistics channels (#258) (detail / githubweb)
  68. Add stack compliance level to the device properties (#275) (detail / githubweb)
  69. Improve logging when commands received by the binding (#274) (detail / githubweb)
  70. ZigBeeSerialPort: Do not synchronize on this when closing the serial (detail / githubweb)
  71. README: fix switched numbers (#278) (detail / githubweb)
  72. README: s/ti2531/cc2531/g (#279) (detail / githubweb)
  73. Add dynamic state description provider (#280) (detail / githubweb)
  74. Allow updates to milestone builds (#778) (detail / githubweb)
  75. Bump ZigBee libraries to 1.1.2 (#775) (detail / githubweb)
  76. Fix for : New Update.ps1 found. Using that… double -SNAPSHOT appended (detail / githubweb)
  77. Added Alert message regarding inclusion of UoM in Synop Binding (#783) (detail / githubweb)
  78. added new ESH MQTT binding to distro (#781) (detail / githubweb)
  79. enable authentication by default (#782) (detail / githubweb)
  80. Revert “enable authentication by default (#782)” (#785) (detail / githubweb)
  81. added HABot feature (#793) (detail / githubweb)
  82. Update demo.items with semantic tags and synonyms (#792) (detail / githubweb)
  83. added ESH io.http and core.semantics bundles to launch config (#795) (detail / githubweb)
  84. switched download urls to new Jenkins instance (#797) (detail / githubweb)
  85. Make the embedded MQTT server less noisy (#798) (detail / githubweb)
  86. Make backup without tmp and cache (#756) (detail / githubweb)
  87. Fix Karaf 4.2.1 broken SSH output using an override (#800) (detail / githubweb)

Quite some changes from just one month of coding - and this is without the changes done on the ESH side (I still don’t know, how we can retrieve such a list from there…)

14 Likes

If we knew which ESH build was included, we could look them up here… https://ci.eclipse.org/smarthome/job/SmartHomeDistribution-Stable/changes.

there is no m5 for me if i try to update with openhabian-config…m4 is the newest version.
im on milestone 4 with openhabian.

$ apt -y install openhab2
Reading package lists... Done
Building dependency tree
Reading state information... Done
openhab2 is already the newest version (2.4.0~M4-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 Like