On 2018-04-25 12:03:54 -0400 (-0400), Doug Hellmann wrote: [...] > Especially now with lower-constraints jobs in place, having plugins > rely on features only available in unreleased versions of service > projects doesn't make a lot of sense. We test that way *between* > services using integration tests that use the REST APIs, but we > also have some pretty strong stability requirements in place for > those APIs. [...]
This came up again a few days ago for sahara-dashboard. We talked through some obvious alternatives to keep its master branch from depending on an unreleased state of horizon and the situation today is that plugin developers have been relying on developing their releases in parallel with the services. Not merging an entire development cycle's worth of work until release day (whether that's by way of a feature branch or by just continually rebasing and stacking in Gerrit) would be a very painful workflow for them, and having to wait a full release cycle before they could start integrating support for new features in the service would be equally unfortunate. As for merging the plugin and service repositories, they tend to be developed by completely disparate teams so that could require a fair amount of political work to solve. Extracting the plugin interface into a separate library which releases more frequently than the service does indeed sound like the sanest option, but will also probably take quite a while for some teams to achieve (I gather neutron-lib is getting there, but I haven't heard about any work toward that end in Horizon yet). -- Jeremy Stanley
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
