I’ve been running OH 2 in the official Docker container with my userdata mapped in as a volume. This means that updating OH is a simple as pulling down the latest image. Because my conf and userdata is maintained outside the container I’ve not suffered any of the problems with upgrades wiping out the configuration.
My understanding is that the installed bindings get saved in userdata/cache and I’ve seen other threads of people talking about preparing for an upgrade by deleting the cache. I’ve never done this.
So my question is, does this mean I’ve been upgrading my OH core but am still running with the original versions of the bindings I installed all this time?
When I do a bundle:list from the console I see the versions but not the build number, or at least no way to definitively tie the bundle version to the OH build number (#577 for the curious).
I know there are changes afoot to improve the upgrade process which may make the answer overcome by events shortly, but in the meantime I’d like to make sure it is right in the Docker docs (I’m working the PR for that and the Migration right now, I’m used to SVN and not github so I’m stumbling through that process slowly).
What version numbers do you see? Since they correspond to their build date it should be relatively easy to workout if they’ve updated recently right? You should see that the eclipse bundles are older, this is because they’re taken less regularly than the daily snapshots built in OH2-addons
I thought that was what the long fourth number was but wasn’t sure. I’m assuming the last four digits of it are the build time?
Regardless I’m seeing mostly 201610101820’s and 201610101214’s with a couple of 201610090111’s thrown in for good measure. If that is the date I would presume these are out of date for a #577 build.
Note, I am using the offline distro, not the online distro, though wonder if that would make a difference.
Presumably if I stop the OH 2 container, delete userdata/cache and restart the container I’ll be in a position to install the latest bindings (or have them auto installed if I add them to addons.cfg). Correct?
Correct, your bindings are about a month old. AFAIK, the latest builds usually align themselves with the timestamp of cloudbees build.
Yes, you should also remove userconfig/tmp to be on the safe side.
Since you’re using the offline version, you will always upgrade to the version that was bundled inside of that distro build, but with snapshots this would be fairly frequently updated anyway and using bundle:update [ID] should bring you up to that date if you don’t want to delete these folders next time.
I’m not completely sure I understand. bundle:update [ID] would be an alternative way to update the bindings? Or is this something I can do after I get things closer to a sane state by deleting cache and temp?
I did the delete path first and took the opportunity to move my installed bindings to addons.cfg and set various other settings that I had previously made in PaperUI. It took a little looking around to solve some errors but it all seems to be running without error now.
Thanks! I’m off to update the Docker tutorial before I commit it to the official docs this weekend.