Open Stack

Excerpts from Ben Swartzlander's message of 2015-09-08 22:22:38 -0400:
> On 09/08/2015 01:58 PM, Doug Hellmann wrote:
> > 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?
> 
> It would be a recognition that most customers don't want to upgrade 
> every 6 months -- they want to skip over 3 releases and upgrade every 2 
> years. I'm sure there are customers all over the spectrum from those who 
> run master to those to do want a new release every 6 month, to some that 
> want to install something and run it forever without upgrading*. My 
> intuition is that, for most customers, 2 years is a reasonable amount of 
> time to run a release before upgrading. I think major Linux distros 
> understand this, as is evidenced by their release and support patterns.

As Jeremy pointed out, we have quite a bit of trouble now maintaining
stable branches. given that, it just doesn't seem realistic in this
community right now to expect support for a 2 year long LTS period.
Given that, I see no real reason to base other policies around the
idea that we might do it in the future. If we *do* end up finding
more interest in stable/LTS support, then we can revisit the
deprecation period at that point.

Doug

> 
> As sdague mentions, the idea of LTS is really a separate goal from the 
> deprecation policy, but I see the two becoming related when the 
> deprecation policy makes it impossible to cleanly jump 4 releases in a 
> single upgrade. I also believe that if you solve the LTS problem, the 
> deprecation policy flows naturally from whatever your supported-upgrade 
> path is: you simply avoid breaking anyone who does a supported upgrade.
> 
> It sounds to me like the current supported upgrade path is: you upgrade 
> each release one at a time, never skipping over a release. In this 
> model, N+1 deprecation makes perfect sense. I think the same people who 
> want longer deprecation periods are the ones who want to skip over 
> releases when upgrade for the reasons I mention.
> 
> -Ben
> 
> * I'm the kind that never upgrades. I don't fix things that aren't 
> broken. Until recently I was running FreeBSD 7 and Ubuntu 8.04. 
> Eventually I was forced to upgrade though when support was dropped. I'm 
> *still* running CentOS 5 though.
> 
> > Doug
> >
> >> -Ben Swartzlander
> >>
> >>> Thanks in advance for your input.
> >>>
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>