Some recent specs have proposed changing some of the API's by either removing parts, or changing them in non-backwards way. Additionally there are some proposals that are light on details of their impact to already supported components.
I propose that deprecation and backwards compatibility should be maintained for at least one release before removing support for the previous implementation. This would result in a process such as A -> A2,B -> B R1 -> R2 -> R3 Where A is the initial implementation A2 is the depricated A interface that likely converts to B back to A B is the new feature R[1,2,3] Releases incrementing. This would require that the interface A is documented in the release notes of R2 as being marked for removal. The A interface can then be removed in R3. This will allow for a reasonable time for down-stream users to learn that the interface they may be using is going away and they can adapt to the new interface before it's the only interface available. -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
