<div dir="ltr">Hi Fellow Developers (and those who interface with keystone at the code level),<div><br></div><div>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).</div>


<div><br></div><div>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.</div>


<div><br></div><div>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.</div>


<div><br></div><div>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.</div><div><br></div><div>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.</div>


<div><br></div><div>Cheers,</div><div>Morgan Fainberg</div><div><br></div><div>IRC: morganfainberg</div></div>