Open Stack

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.

Cheers,
Morgan Fainberg

IRC: morganfainberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131015/144c63c3/attachment.html>