Open Stack

> 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 <bdobrelia at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160310/488910d7/attachment.html>