Open Stack

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

-- 
Sean Dague
http://dague.net