> Good idea. That should be done despite on any decision we will take. Currently you have to specify which releases your plugin supports [0]. So I can take my plugin developed for 8.0 and install it on Fuel-9.0 (I actually did it and it worked just fine). But I won't be able to enable this plugin for "mitaka-9.0" release because plugin was not developed and tested for it, so it does not have "miraka-9.0" in "releases" list [0]. So I don't quite understand how new "validated_against" parameter will differ from existing "releases" list.
Regards, Alex [0] https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21 On Thu, Mar 10, 2016 at 10:22 AM, Bogdan Dobrelya <bdobre...@mirantis.com> wrote: > On 10.03.2016 08:30, Mike Scherbakov wrote: > > Hi folks, > > in order to make a decision whether we need to support example plugins, > > and if actually need them [1], I'd suggest to discuss more common things > > about plugins. > > > > My thoughts: > > 1) This is not good, that our plugins created for Fuel 8 won't even > > install on Fuel 9. By default, we should assume that plugin will work at > > newer version of Fuel. However, for proper user experience, I suggest to > > create meta-field "validated_against", where plugin dev would provide > > versions of Fuel this plugin has been tested with. Let's say, it was > > tested against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest > > to show a warning saying about risks and the fact that the plugin has > > not been tested against 9. We should not restrict intsallation against > > 9, though. > > Good idea. That should be done despite on any decision we will take. > > > > > 2) We need to keep backward compatibility of pluggable interface for a > > few releases. So that plugin developer can use pluggable interface of > > version x, which was supported in Fuel 6.1. If we still support it, it > > would mean (see next point) compatibility of this plugin with 6.1, 7.0, > > 8.0, 9.0. If we want to deprecate pluggable interface version, we should > > announce it, and basically follow standard process of deprecation. > > > > 3) Plugin's ability to work against multiple releases of Fuel > > (multi-release support). If if..else clauses to support multiple > > releases are fairly minimal, let's say take less that 10% of LOC, I'd > > suggest to have this supported. Just because it will be easier for > > plugin devs to support their plugin code (no code duplication, single > > repo for multiple releases). > > > > Thoughts? > > > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html > > -- > > Mike Scherbakov > > #mihgen > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev