On 3 September 2015 at 08:22, Thierry Carrez <thie...@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
__________________________________________________________________________ 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
