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.
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
Let’s first pretend there are no breaking changes in the add-ons. From a strict package install and upgrade standpoint only.
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…
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.
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!
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…”
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?
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 ) 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…
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
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.
Update demo.items with semantic tags and synonyms (#792) (detail / githubweb)
added ESH io.http and core.semantics bundles to launch config (#795) (detail / githubweb)
switched download urls to new Jenkins instance (#797) (detail / githubweb)
Make the embedded MQTT server less noisy (#798) (detail / githubweb)
Make backup without tmp and cache (#756) (detail / githubweb)
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…)
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.