Re: [Engine-devel] UI Plugin API improvements

Hi guys, These changes are already present in oVirt git "master" branch, so if your current work branch is based on "master", you can fetch these changes via "git fetch && git rebase origin/master". (No need to download and apply patches manually from git web interface, as these patches are merged already.) You're right, this is something I've been thinking about lately as well. Since UI Plugins is oVirt feature, we can have two levels of versioning: * level-1 = oVirt version, e.g. "3.2" * level-2 = UI Plugin feature/API version, e.g. "1" [the number always goes up, i.e. new oVirt release does *not* reset this number] As Itamar mentioned below, UI plugins distributed as RPM packages can use "level-1" version to make sure that given plugin is installed only for supported oVirt version. [file:/usr/share/ovirt-engine/ui-plugins/showcase.json] { "name": "showcase", "apiVersion": "xxx", "url": "/webadmin/webadmin/plugin/showcase/start.html", "resourcePath": "showcase-files" } [/file] In the example above, "apiVersion" could follow interval-like syntax, similar to [http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html]: * "[2]" --> apiVersion == 2 * "[2,3]" --> 2 <= apiVersion <= 3 * "(2,)" --> 2 < apiVersion Such API compliance checking could be done early on during UI plugin discovery process, with "apiVersion" attribute being optional within the plugin descriptor. (If not specified, the plugin meta-data & configuration would be always sent alongside WebAdmin, just like today.) As suggested by René, there would still be an API function to determine current UI Plugin API version. This could be used to support situations like "plugin supports version 2 and above [via apiVersion], but for version 3 it needs to do something differently". We should make RPM packaging a good habit (best practice?) documented on oVirt wiki, but IMHO oVirt version ("level-1") is not enough, we should also track feature/API version ("level-2") separately. Example: * oVirt version 3.2 --> feature/API version 1 * oVirt version 3.3 --> feature/API version 2 (For RHEV, where backports are important, we could have multiple feature/API versions within a single RHEV version.) IIUC this can be covered with combination of "apiVersion" + runtime API like api.getVersion(). So guys, what do you think? Regards, Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "René Koch" <r.koch(a)ovido.at&gt; Cc: "Vojtech Szocs" <vszocs(a)redhat.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt; Sent: Saturday, March 30, 2013 11:30:49 PM Subject: Re: [Engine-devel] UI Plugin API improvements On 03/30/2013 03:12 PM, René Koch wrote: > Hi Vojtech, > > Thanks a lot for the information. > interesting point. maybe less of an issue if the ui plugin is distributed in rpm form, and can validate minimal version. but if a single codebase for the uiplugin is to support multiple versions for deployment, it may want to make some features available only if engine version is X or >X. so just wondering: - do you see uiplugins distributed as rpms or some other way? - do you see uiplugin codebase trying to accomodate multiple versions, or branch/version similar to supported engine, and one needs latest engine for latest uiplugin, etc. Thanks, Itamar