<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 8, 2015 at 9:10 AM, Doug Hellmann <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd like to come up with some way to express the time other than<br>
N+M because in the middle of a cycle it can be confusing to know<br>
what that means (if I want to deprecate something in August am I<br>
far enough through the current cycle that it doesn't count?).<br>
<br>
Also, as we start moving more projects to doing intermediate releases<br>
the notion of a "release" vs. a "cycle" will drift apart, so we<br>
want to talk about "stable releases" not just any old release.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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'.</div><div><br></div><div>dt</div></div><div><br></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>