Open Stack

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.
> >
>