<div dir="ltr">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.<div><br></div><div>I propose that deprecation and backwards compatibility should be maintained for at least one release before removing support for the previous implementation.</div><div><br></div><div>This would result in a process such as</div><div><br></div><div>A -> A2,B -> B</div><div>R1 -> R2    -> R3</div><div><br></div><div>Where </div><div>A is the initial implementation</div><div>A2 is the depricated A interface that likely converts to B back to A</div><div>B is the new feature</div><div><br></div><div>R[1,2,3] Releases incrementing.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">--</p>
<p dir="ltr">Andrew Woodward</p>
<p dir="ltr">Mirantis</p>
<p dir="ltr">Fuel Community Ambassador</p>
<p dir="ltr">Ceph Community</p>
</div>