Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150629/374828d4/attachment.html>