+1 to Stas, supplanting VCS branches with code duplication is a path to madness and despair. The dubious benefits of a cross-release backwards compatible plugin binary are not worth the code and infra technical debt that such approach would accrue over time.
On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin wrote: > It changes mostly nothing for case of furious plugin development when big > parts of code changed from one release to another. > > You will have 6 different deployment_tasks directories and 30 a little bit > different files in root directory of plugin. Also you forgot about > repositories directory (+6 at least), pre_build hooks (also 6) and so on. > It will look as hell after just 3 years of development. > > Also I can't imagine how to deal with plugin licensing if you have Apache > for liberty but BSD for mitaka release, for example. > > Much easier way to develop a plugin is to keep it's source in VCS like Git > and just make a branches for every fuel release. It will give us > opportunity to not store a bunch of similar but a little bit different > files in repo. There is no reason to drag all different versions of code > for specific release. > > > On other hand there is a pros - your plugin can survive after upgrade if it > supports new release, no changes needed here. > > On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov <ashtoko...@mirantis.com> > wrote: > > > Fuelers, > > > > We are discussing the idea to extend the multi release packages for > > plugins. > > > > Fuel plugin builder (FPB) can create one rpm-package for all supported > > releases (from metadata.yaml) but we can specify only deployment scripts > > and repositories per release. > > > > Current release definition (in metadata.yaml): > > - os: ubuntu > > version: liberty-8.0 > > mode: ['ha'] > > deployment_scripts_path: deployment_scripts/ > > repository_path: repositories/ubuntu > > > > So the idea [0] is to make releases fully configurable. > > Suggested changes for release definition (in metadata.yaml): > > components_path: components_liberty.yaml > > deployment_tasks_path: deployment_tasks_liberty/ # <- folder > > environment_config_path: environment_config_liberty.yaml > > network_roles_path: network_roles_liberty.yaml > > node_roles_path: node_roles_liberty.yaml > > volumes_path: volumes_liberty.yaml > > > > I see the issue: if we change anything for one release (e.g. > > deployment_task typo) revalidation is needed for all releases. > > > > Your Pros and cons please? > > > > [0] https://review.openstack.org/#/c/271417/ > > --- > > WBR, Alexey Shtokolov > > > > __________________________________________________________________________ > > 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 > > > > > > > -- > with best regards, > Stan. > __________________________________________________________________________ > 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