On Tue, Oct 15, 2013 at 6:05 PM, Morgan Fainberg <m...@metacloud.com> 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.
With a more stringent end goal in mind (release - 1), I think functional documentation would be a great step in the right direction, and an easy ask for developers & reviewers. The two most important capabilities are to provide warnings for when something may be completely removed (release +1 or +2) and to point to the new method/function (where possible). The immediate use case for this patch is to deprecate v2.0 controllers, but there's no reason why it couldn't be adapted to driver interfaces, etc: https://review.openstack.org/#/c/50486/ > > 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 > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev