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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
