On Tue, Oct 15, 2013 at 7:05 PM, Morgan Fainberg <[email protected]> wrote:
> Hi Fellow Developers (and those who interface with keystone at the code > level), > > I wanted to reach out to the ML and see what the opinions were about > starting to stabilize the internal APIs (wherever possible) for the > keystone project (I would also like to see similar work done in the other > fully integrated projects, but I am starting with a smaller audience). > > I believe that (especially in the case of things like identity_api -> > assignment_api) we should start supporting the concept of Release -1 > (current release, and previous release) of a given internal API. While > this isn't feasible everywhere, if we can't maintain at least an exception > being raised that indicates what "should" be called would be ideal for the > release the change occurred in. > > This will significantly help any developers who have custom code that > relies on these APIs to find the locations of our new internal APIs. > Perhaps the "stub" function/method replacement that simply raises a "go > used this new method/function" type exception would be sufficient and make > porting code easier. > > This would require at the start of each release a "cleanup" patchset that > removed the stub or old methods/functions that are now fully deprecated. > > So with that, lets talk about this more in depth see where it lands. I > want to weed out any potential pitfalls before a concept like this makes it > anywhere beyond some neural misfires that came up in a passing discussion. > It may just not be feasible/worth the effort in the grand scheme of things. > Making updates easier would be nice, and the abstract base class work should help with that. On the other hand, as a deployer who has had to rewrite our custom integration a few times in the past 6 months or so, I would also welcome some stability in the plugin APIs. I understand the need to provide flexibility and updated features for new REST APIs, but I hope we can find a way to migrate more smoothly or make newer features optional in the plugins themselves. DreamHost will have several developers at the summit; is there a session to talk about approaches for this that we should make sure to attend? Doug > > Cheers, > Morgan Fainberg > > IRC: morganfainberg > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
