> So the deprecation message in the patch says:
>
> LOG.warning(_('XML support has been deprecated and will be
> removed in the Juno release.'))
>
> perhaps that should be changed :-)
Maybe, but I think we can continue with the plan to rip it out in Juno.
In the past when we've asked, there has been an overwhelming amount of
"meh" regarding removing it. We've considered it several times, and
we've now drawn a line in the sand. Personally, I'm fine with doing
this, and I think the support from the core team that +A'd the heck out
of it probably means that there is wide support for it.
> In terms of user facing changes we can't do a whole lot - because they
> are inherently changes in how users communicate with API. And not just
> in terms of parameter names, but where and how they access the
> functionality (eg url paths change). In the past we've made
> mistakes as to where or how functionality should appear, leading to
> weird inconsistencies.
>
> So either we can't fix them or in cases where we preserve backwards
> compatibility we end up with dual maintenance cost (our test load
> still doubles), but often having to be implemented in a way which costs
> us more in terms of readability because the code becomes spaghetti.
I think it can be done without it turning into a mess. Non-trivial for
sure, but not impossible. And if not, I still expect most users would
prefer stability over purity.
--Dan
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
