Using lazy census here, I will update the wiki with this process. On Mon, Jun 29, 2015 at 4:22 PM Andrew Woodward <xar...@gmail.com> wrote:
> 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 > -- -- 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