Hi everyone, A feature deprecation policy is a standard way to communicate and perform the removal of user-visible behaviors and capabilities. It helps setting user expectations on how much and how long they can rely on a feature being present. It gives them reassurance over the timeframe they have to adapt in such cases.
In OpenStack we always had a feature deprecation policy that would apply to "integrated projects", however it was never written down. It was something like "to remove a feature, you mark it deprecated for n releases, then you can remove it". We don't have an "integrated release" anymore, but having a base deprecation policy, and knowing which projects are mature enough to follow it, is a great piece of information to communicate to our users. That's why the next-tags workgroup at the Technical Committee has been working to propose such a base policy as a 'tag' that project teams can opt to apply to their projects when they agree to apply it to one of their deliverables: https://review.openstack.org/#/c/207467/ Before going through the last stage of this, we want to survey existing projects to see which deprecation policy they currently follow, and verify that our proposed base deprecation policy makes sense. The goal is not to dictate something new from the top, it's to reflect what's generally already applied on the field. 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 Thanks in advance for your input. -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
