Open Stack

On Tue, Oct 15, 2013 at 6:05 PM, Morgan Fainberg <m at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph