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

Dean Troyer dtroyer at gmail.com
Tue Sep 8 16:20:47 UTC 2015


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

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150908/957c41cd/attachment.html>


More information about the OpenStack-dev mailing list