Open Stack

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.

-Ben Swartzlander


> Thanks in advance for your input.
>