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'. >>>> >>>> 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. >> >> 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.
OK, so it seems we have convergence around: "config options and features will have to be marked deprecated for a minimum of one stable release branch and a minimum of 3 months" I'll add some language in there to encourage major features to be marked deprecated for at least two stable release branches, rather than come with a hard rule defining what a "major" feature is. -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
