Excerpts from Ben Swartzlander's message of 2015-09-08 13:32:58 -0400: > On 09/03/2015 08:22 AM, Thierry Carrez wrote: > > 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 > > I think any discussion of a deprecation policy needs to be combined with > a discussion about LTS (long term support) releases. Real customers (not > devops users -- people who pay money for support) can't deal with > upgrades every 6 months. > > Unavoidably, distros are going to want to support certain releases for > longer than the normal upstream support window so they can satisfy the > needs of the aforementioned customers. This will be true whether the > deprecation policy is N+1, N+2, or N+3. > > It makes sense for the community to define LTS releases and coordinate > making sure all the relevant projects are mutually compatible at that > release point. Then the job of actually maintaining the LTS release can > fall on people who care about such things. The major benefit to solving > the LTS problem, though, is that deprecation will get a lot less painful > because you could assume upgrades to be one release at a time or > skipping directly from one LTS to the next, and you can reduce your > upgrade test matrix accordingly.
How is this fundamentally different from what we do now with stable releases, aside from involving a longer period of time? Doug > > -Ben Swartzlander > > > Thanks in advance for your input. > > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
