[openstack-dev] [all] Base feature deprecation policy

gord chung gord at live.ca
Tue Sep 8 22:10:29 UTC 2015



On 08/09/2015 5:29 PM, Sean Dague wrote:
> On 09/08/2015 03:32 PM, Doug Hellmann wrote:
>> Excerpts from Sean Dague's message of 2015-09-08 14:11:48 -0400:
>>> On 09/08/2015 01:07 PM, Doug Hellmann wrote:
>>>> Excerpts from Dean Troyer's message of 2015-09-08 11:20:47 -0500:
>>>>> On Tue, Sep 8, 2015 at 9:10 AM, Doug Hellmann
>>>>>> I'd like to come up with some way to express the time other than
>>>>>> N+M because in the middle of a cycle it can be confusing to know
>>>>>> what that means (if I want to deprecate something in August am I
>>>>>> far enough through the current cycle that it doesn't count?).
>>>>>>
>>>>>> Also, as we start moving more projects to doing intermediate releases
>>>>>> the notion of a "release" vs. a "cycle" will drift apart, so we
>>>>>> want to talk about "stable releases" not just any old release.
>>>>>>
>>>>> I've always thought the appropriate equivalent for projects not following
>>>>> the (old) integrated release cadence was for N == six months.  It sets
>>>>> approx. the same pace and expectation with users/deployers.
>>>>>
>>>>> For those deployments tracking trunk, a similar approach can be taken, in
>>>>> that deprecating a config option in M3 then removing it in N1 might be too
>>>>> quick, but rather wait at least the same point in the following release
>>>>> cycle to increment 'N'.
>>>>>
>>>>> dt
>>>>>
>>>> Making it explicitly date-based would simplify tracking, to be sure.
>>> I would agree that the M3 -> N0 drop can be pretty quick, it can be 6
>>> weeks (which I've seen happen). However N == six months might make FFE
>>> deprecation lands in one release run into FFE in the next. For the CD
>>> case my suggestion is > 3 months. Because if you aren't CDing in
>>> increments smaller than that, and hence seeing the deprecation, you
>>> aren't really doing the C part of CDing.
>>>
>>>      -Sean
>>>
>> Do those 3 months need to span more than one stable release? For
>> projects doing intermediary releases, there may be several releases
>> within a 3 month period.
> Yes. 1 stable release branch AND 3 months linear time is what I'd
> consider reasonable.
>
> 	-Sean
>
while the pyro in me would like to burn things asap, my fellow 
contributors won't let me so Ceilometer typically has done 
deprecate->deprecate->remove. but agree with sdague, the bare minimum 
should be ^. operators will yell, don't make them yell.

cheers,

-- 
gord




More information about the OpenStack-dev mailing list