Open Stack

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