Open Stack

The aim wasn't to be focused on what's easiest for Horizon at all; it was a suggestion to let plugins keep moving during brief periods of instability when people make mistakes. We're aware of the plugins need for stability and correct deprecation, but we won't catch everything.

That said, there's been significant enough push back against the suggestion that I'll rethink it. I'll make sure we discuss the horizon / openstack_dashboard split again at the summit too.

Thanks everyone
Rob

On 21 July 2016 at 17:36, David Lyle <dklyle0 at gmail.com<mailto:dklyle0 at gmail.com>> wrote:
I think basing the plugins against master is the best solution since
the plugin in development will want to work with the matching horizon
release. Finding issues sooner and hopefully one at a time is a lot
easier to address than a bundle of them at the end of a release cycle.
Hopefully, Horizon doesn't break plugins on a regular basis. If we
are, then we are not being focused enough around supporting plugins by
maintaining compatibility and focused too much around what's easiest
for Horizon in the development process. Horizon is no longer at the
top of the stack, we should develop with that awareness. Of course,
breaking changes will happen, but they should be limited and isolated.

David

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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/20160721/22c27264/attachment.html>