Open Stack

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160310/c0f9af50/attachment.html>