ExtensionService for snapshot addons

[5iver]

Is there any reason why one of these couldn't be implemented to allow users with a stable, testing or snapshot OH install to select and install the latest snapshot version of an addon? Currently, one needs to download and manually install the addon and any dependencies, or run something like this in Karaf...

bundle:install https://openhab.jfrog.io/openhab/online-repo-snapshot/2.5/org/openhab/addons/bundles/org.openhab.binding.zwave/2.5.0-SNAPSHOT/org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar

For the first method, finding the URL for the addon in Jenkins is easy. For the second, it's not that much more difficult to find the URL in https://openhab.jfrog.io/openhab/online-repo-snapshot/2.5/org/openhab/addons/bundles/. It would just be a lot easier to have this built into a UI.

[kaikreuzer]

Well, the main reason is that there is no guarantee of compatibility and including it in the UI would suggest the user that there is.
After all, it is hardly every a good idea to install the latest snapshot of a binding on the latest release of the runtime. We always tell people to also upgrade their runtime as well. If using a snapshot runtime with snapshot add-ons, people seem to love risk, so in this case, I'd say it is fine to offer an easy mechanism. But this should in theory actually already be in place, by simply uninstalling/installing the add-on in question. The main issue is that this mechanism does not seem to work, see openhab/openhab-distro#450. So assuming openhab/openhab-distro#450 was solved, would that solve your issue as well?

[5iver]

So assuming openhab/openhab-distro#450 was solved, would that solve your issue as well?

Unfortunately no, since I was looking to make it easier for everyone to get a snapshot release of an addon. It did not look to me as though the resolution of that issue would not help users with a stable or milestone release of OH. The addon where I see this being the most beneficial is the zwave binding, which is continuously receiving updates to the device database.

What caused me to pose this question was imagining ScriptEngine addons for scripted automation that contain the helper libraries... both core and community. As updates occur and new things are added, I'd like to see simple upgrade paths, such as manually clicking an update button in a UI, or better yet, a mechanism that would automate the update of the addons. We'll eventually get an ExtensionService together for rule templates, which will take care of the scripts. But you will end up with a dependency between a rule template and a particular version of a Jython ScriptEngine addon (which contains a specific community library) needed by the script... or a dependency on a particular version of OH.

I just think we need an easy way to upgrade addons, and/or a mechanism that will keep specific ones updated with the latest version. The bigger discussion would be how to implement, maintain, and visually display the individual versions of each addon and the minimum required versions of required bundles and APIs. I thought I remembered another discussion about this, but I couldn't find it... I didn't search the ESH repo though.

[Celaeno1]

So assuming openhab/openhab-distro#450 was solved, would that solve your issue as well?

I do not think anymore, that it would be a good idea to solve this. There are good reasons to keep the old binding version in tmp folder.
If someone expects the latest snapshot solves an existing issue, but then he determines that it is not resolved, then he could never return to its old state (without a backup), because the old snapshot binding is nowhere to be found.

[J-N-K]

I think this one is solved with having #2405 and #2592 merged.