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 <[email protected]<mailto:[email protected]>> 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: [email protected]?subject:unsubscribe<http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
