<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 3 September 2015 at 08:22, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...<br>
In particular, the current proposal says:<br>
<br>
"At the very minimum the feature [...] should be marked deprecated (and<br>
still be supported) in the next two coordinated end-of-cyle releases.<br>
For example, a feature deprecated during the M development cycle should<br>
still appear in the M and N releases and cannot be removed before the<br>
beginning of the O development cycle."<br>
<br>
That would be a n+2 deprecation policy. Some suggested that this is too<br>
far-reaching, and that a n+1 deprecation policy (feature deprecated<br>
during the M development cycle can't be removed before the start of the<br>
N cycle) would better reflect what's being currently done. Or that<br>
config options (which are user-visible things) should have n+1 as long<br>
as the underlying feature (or behavior) is not removed.<br>
<br>
Please let us know what makes the most sense. In particular between the<br>
3 options (but feel free to suggest something else):<br>
<br>
1. n+2 overall<br>
2. n+2 for features and capabilities, n+1 for config options<br>
3. n+1 overall<br></blockquote><div><br></div><div>ironic does n+1 for config options and features. It is possible that ironic did n+2 as well but if so, I don't recall.</div><div><br></div><div>Thanks for asking!</div><div><br></div><div>--ruby</div></div></div></div>