Open Stack

On 3 September 2015 at 08:22, Thierry Carrez <thierry at openstack.org> wrote:

> ...
> In particular, the current proposal says:
>
> "At the very minimum the feature [...] should be marked deprecated (and
> still be supported) in the next two coordinated end-of-cyle releases.
> For example, a feature deprecated during the M development cycle should
> still appear in the M and N releases and cannot be removed before the
> beginning of the O development cycle."
>
> That would be a n+2 deprecation policy. Some suggested that this is too
> far-reaching, and that a n+1 deprecation policy (feature deprecated
> during the M development cycle can't be removed before the start of the
> N cycle) would better reflect what's being currently done. Or that
> config options (which are user-visible things) should have n+1 as long
> as the underlying feature (or behavior) is not removed.
>
> Please let us know what makes the most sense. In particular between the
> 3 options (but feel free to suggest something else):
>
> 1. n+2 overall
> 2. n+2 for features and capabilities, n+1 for config options
> 3. n+1 overall
>

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.

Thanks for asking!

--ruby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150903/3d371a02/attachment.html>